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ABSTRACT 


This  report  describes  the  Pascal-based  implementation  of 
DDL  (Digital  Design  Language)  and  its  simulator. 
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Chapter  1 
INTRODUCTION 

This  report  is  one  oi  tuo  manuals  describing  a compi- 
ler and  simulator  ior  DDL-P,  a subset  oi  DDL  (Digital  Design 
Language).  DDL  is  a language  ior  describing  the  behavior  o.i 
digital  systems  at  the  Boolean  equation.  register  transier, 
and  algorithmic  levels.  It  uses  a iinite  state  machine  no- 
tation and  it  may  be  used  to  describe  systems  over  a wide 
range  oi  levels. 

DDL  uas  originally  iormulated  by  Duley  at  the  Univer- 
sity oi  Wisconsin  in  1967  (5.  6.  31.  A translator  and  simu- 
lator ior  a subset  oi  DDL  were  implemented  in  FORTRAN  (1,  7, 
4,  8.  9,  101.  In  1971-73.  J.  Duley.  B.  Clark,  and  J.  Uelsch 
implemented  an  interactive  simulation  system  ior  a subset  oi 
DDL  (with  modiiied  syntax)  on  the  HP  2100  system  in  HP-Algol 
at  Hewlett-Packard  Laboratories.  The  DDL-P  language,  compi- 
ler, and  simulator  are  based  on  this  HP  implementation.  In 
order  to  enhance  portability  the  system  uas  rewritten  in 
PASCAL  on  the  DEC-20  system  under  the  TOPS-20  Operating  Sys- 
tem at  Staniord  University.  Small  changes  were  made  to  the 
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syntax,  aainly  to  onhsnos  ths  roadability.  Tha  systaa  will 
still  aeoapt  tha  input  loraat  oi  tha  original  HP-Algol  var- 
aion. 

This  raport  dasoribas  tha  DDL-P  subsat  oi  tha  languaga 
as  it  was  iapleaented  at  Stanford.  Savaral  examples  are 
given  together  with  instructions  for  using  tha  coapilar  on 
tha  LOTS  DEC-20  systaa  at  Stanford.  Tha  appendices  contain 
a list  of  tha  error  aassagas  and  a foraal  BNF  definition  of 
tha  languaga  accepted  by  tha  coapilar.  k conpanion  manual 
describes  tha  use  of  tha  siaulator  and  its  coamand  languaga 
12). 


Chapter  2 


CHARACTER  SET,  IDENTIFIERS,  AND  CONSTANTS 


AlBlClDlElFlGlHlIlJlKlLlMl 
HlOtPlQlRlSlTlUlV lUlXlYlZl 
a Iblc Id  lei f Ig Ih li I j Ik lllml 
nlolplq Irlsltlulvlwlxlylz 


0111213141516171819 


digit 


DDL-P  uses  a subset  of  the  7-bit  ASCII  character  set 


including  the  letters  A-Z,a-z  and  the  digits  0-9.  Upper  and 


lower  case  letters  are  considered  to  be  equivalent 


listing  generated  by  DDL-P,  all  letters  are  printed  in  upper 


The  following  non-alphanumeric  characters  are  also 


used  ("SSR"  stands  for  "state  sequencing  register")  ■ 


Octal  Char 


Comment  delimiter 

NOT  EQUAL  relational  operator  or  SSR  marker 
(Optional)  end  of  file  marker 
Expression,  parameter  list,  or  SSR  value 
delimiter 

Expression,  parameter  list,  or  SSR  value 
delimiter 
AND  operator 
OR  operator 


0 5 *4 

055 

056 


057  / 

072  i 

073  i 

074  < 

075  « 

076  > 

)00  S 

133  I 

135  ] 

136  ♦ 

137 


List  separator 

NOT  logical  operator 

Declaration  and  conditional  terminator 
or  indicator  lor  1 e 1 t- jus t i 1 ica t i on  in 
constants 
State  terminator 

Label  delimiter  or  value  range  indicator 

Separator  in  condit;  -nals 

LESS  THAN  relational  operator 

Immediate  transier  action 

GREATER  THAN  relational  operator 

Set-terminal  action,  octal  constant  indicator 

Dimension  or  subscript  delimiter 

Dimension  or  subscript  delimiter 

Case-selecting  expression  delimiter 

Delayed  transfer  action 


In  addition  to  the  above  symbols.  DDL-P  uses  the  fol 
lowing  multiple-character  special  symbols: 


Symbol  Use 


I ♦ 1 
(♦) 

(-) 

>» 

<« 

( » ) 

-> 

»> 

<- 

CASE 

DO 

ENDCASE 

IF 

THEN 

ELSE 

END  I F 

END 

CON 

RED 

EXT 

HEAD 

TAIL 

TIME 

INPUT 


EXCLUSIVE-OR  logical  operator 
Arithmetic  addition  operator 

Arithmetic  subtraction  or  negation  operator 
GREATER-THAN-OR-EQUAL  relational  operator 
LESS-THAN-OR-EQUAL  relational  operator 
EQUALS  relational  operator 
Goto  or  set-next-state  action 

Set-next-state  action  (save  state  for  RETURN) 

Delayed  transfer  action 

Conditional  operator 

Conditional  separator 

Conditional  terminator 

Conditional  operator 

Conditional  separator 

Conditional  separator 

Conditional  terminator 

Declaration  terminator 

Concatenation  operator 

Reduction  operator 

Replication  operator 

Head  substring  operator 

Tail  substring  operator 

Time  specification  action 

Input  action 
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OUTPUT  Output  action 

LEVEL  Return  to  higher  level  state  machine 

RETURN  Set-next-state  action  (by  RETURN) 

REGISTER  Register  declaration  header 

MEMORY  Memory  declaration  header 

TERMINAL  Terminal  declaration  header 

OPERATION  Operation  section  header 

CONTROL  State  machine  declaration  header 


All  printing  characters  not  mentioned  above  are  illegal 
characters  and  should  appear  only  in  comments. 


Note  that  on  input,  the  compiler  maps  the  characters 


H}"»  and  DEL  (ASCII  code  177  octal)  into 
"8",  "I",  "\H,  •*]",  and  respectively.  For  this 
reason,  avoid  the  use  of  " ' , H { " » etc. 


letter_or_digit  ::=  letter  I digit 

identifier  = letter  { II  letter_or_digit  }*** 


Identifiers  in  DDL-P  are  made  up  of  letters  and  digits 
Upper  and  louer  case  letters  are  equivalent. 
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Examples 


RegisterName 

rEglsTeRnAmE  (equivalent  to  RegisterName) 

IdentifiersCanBeVeryLong 
m 1n2 

Note  that  in  the  last  example>  ”2”  would  be  interpreted 
as  a subscript  if  "min"  were  previously  declared.  This  is 
discussed  in  Section  5.1.1. 

Identifiers  must  start  with  a letter  and  may  be  of  any 
length  up  to  132  characters.  The  alphabetic  special  symbols 
listed  in  Section  2.1  are  keywords  and  may  not  be  used  as 
identifiers. 

Unless  otherwise  noted  in  this  manual,  all  identifiers 
declared  in  DDL-P  are  global;  that  is,  an  identifier  may 
only  be  declared  once  in  a DDL-P  description. 
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hex.digi t 


s : * digit  I A IB  1C 


c l r 


octal _digit  ;:«0I1|2I3I4I5I6I7 
q ua r t a l_d i g i t ««■  0 I 1 I 2 I 3 
bit  i :■  0 I 1 

decimal.constant  m digit  { II  digit  }•** 

constant  n«  dacimal_constant 

I decimal_constant  II  B { II  . ) II  bit 

{ I I bit  )•** 


decimal .constant 


decimal .constant 


I decimal.constant 
I decimal.constant 


Q { I I . ) 
quartal.digit 
quartal.d ig i t }*#* 
a { I I . } 
octal.d ig i t 
octal.digit  }*** 

D I I decimal.constant 
Hill.) 
hex.digit 
hex.digit  }*** 


Every  constant  in  DDL-P  has  tuo  attributes.  its  value 
and  its  length  in  bits.  Generally  the  length  of  » constant 
is  given  explicitly.  The  general  format  for  a constant  fol- 
lows : 
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Length  (in  decimal)  of  constant  in  bits, 
followed  by  base  designator  B base  2 

Q base  4 
* base  8 
D base  10 
H base  16  » 

optionally  followed  by  *.*  denoting  1 ef t- jus t i f icet i on . 
followed  by  value  (before  1 ef t- jus t i f icet  i on ) 
in  appropriate  base. 


The  length  of  a constant  must  in  the  range 

0 < length  <-  256. 


If  a constant  is  1 ef t- jus t i f ied . then  it  is  truncated 
on  the  right  or  padded  on  the  right  with  zeroes  to  make  it 
the  proper  length.  Decimal  constants  may  not  be  left-justi- 
fied. 

Note  that  leading  zeroes  in  the  left-most  digit  of  a 
1 *f t- jus t i f i ed  constant  ARE  NOT  truncated;  hence  left-justi- 
fication does  not  imply  that  the  most  significant  bit  is  set 
tu  one. 


If  a constant  is  not  1 ef t- jus t i f ied , then  it  is  trun- 
cated on  the  left  or  extended  on  the  left  with  zeroes  to 
make  it  the  proper  length. 

Examples 

Constant  Binary  representation 


6D22 
1 B 1 
8B101 
8B.  101 


010110 

1 

00000101 

10100000 


2B101  01 

2 B . 10  1 10 

16Q2321  0000000010111001 

1181 367  01011110111  n 

6H3C  111100 

1 OH . 74  0 1 1 10  10000 

A decimal  constant  may  ba  written  without  the  length 
speciiication  and  base  designator  'D'»  in  which  case  a de- 
fault length  of  16  is  assumed.  The  value  specified  must 
then  be  in  the  range  0 <>  value  <■  65535. 

Examples 

Constant  Binary  representation 

1 0000000000000001 

10  0000000000001010 

100  0000000001100100 

4095  0000  1 1 1 1 1 1 1 1 1 1 1 1 

I 

2.4  COMMENTS 

A comment  Cany  text  not  containing  a is  contained 

on  one  line  end  enclosed  in  double  quotes  •"•« 

" This  is  a valid  comment  . " 

The  second  double  quote  may  be  omitted.  in  which  case 
the  entire  line  following  the  first  ""  is  treated  as  a com- 
ment < 

* This  is  also  a valid  comment  . 
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Comments  are  ignored  by  DDL-P  and  may  be  inserted 
freely  for  documentation  anywhere  blanks  are  permitted  (see 
next  section). 

2.5  DDL-P  DESCRIPTION  FORMAT 

A DDL-P  description  is  free-format.  Blanks  may  be  in- 
serted at  will  to  improve  readability*  except  that  blanks 
must  not  be  embedded  in  constants,  identifiers.  or  the  mul- 
tiple-character special  symbols  listed  in  Section  2.1.  Com- 
ments may  also  appear  anywhere  blanks  are  allowed. 

DDL-P  expands  the  non-printing  character  HT  (tab.  ASCII 
code  Oil  octal)  to  blanks;  tabs  may  appear  anywhere  blanks 
are  permitted.  All  other  non-printing  characters  (except 
DEL.  noted  in  Section  2.1)  are  ignored. 

All  lines  should  be  no  longer  than  132  characters 
(AFTER  tabs  are  expanded).  DDL-P  truncates  longer  lines. 
The  end  of  a line  may  occur  anywhere  blanks  are  allowed. 


Chapter  3 

DDL-P  DESCRIPTION  STRUCTURE 


r~ 

dd l_d esc r i p t i on 

««■  declaration  {operation_decl } 

| 

control_decl  (A) 

1 

declaration  > > * 

rag ister_dec 1 (memory.dec 1 ) 

l 

{ terminal_decl } 

1 

1 

memory_decl  { terminal_dec 1 } 

L 

1 

terminal_decl 

A DDL-P  description  in  ganaral  contains  the  following 
sections  in  the  order  givens 
Chapter 

4 REGISTER  declarations  \ 

4 MEMORY  declarations  ) at  least  one  of  these 

6 TERMINAL  declarations  / must  be  present 

OPERATION  section  - optional 
CONTROL  section 


) at  least  one  of  these 
must  be  present 


The  REGISTER  and  MEMORY  sections  contain  declarations 
of  synchronous  and  asynchronous  storage  elements,  respec- 
tively. The  terminal  section  contains  declarations  of  com- 
binational networks.  The  OPERATION  section  defines  data 
transfers  which  may  occur,  along  with  optional  timing  infor- 
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nation.  Tha  CONTROL  saction  contains  tha  finite  atata  Bi- 
china. which  controls  tha  usa  of  tha  physical  facilities 
praviously  daiinad.  Tha  dollar  sign  at  tha  end  of  tha  des- 
cription is  optional. 

Each  of  thasa  sections  is  presented  in  turn  in  the  fol- 
lowing chapters,  with  a discussion  of  Boolean  expressions  in 
chapter  5. 


Chapter  4 

REGISTER  AND  MEMORY  DECLARATIONS 

DDL-P  allows  the  declaration  of  synchronous  and  asynch- 
ronous storage  elements  in  REGISTER  and  MEMORY  declarations, 
respectively. 


4.1  REGISTER  DECLARATIONS 


register.decl  ««■  REGISTER  register.spec 

{ . register_spec  }««*  . 

register.spec  ss»  {♦}  identifier 

{ ( (constants)  constant]  } 
I identifier  [ (constants)  constant  , 
{constants}  constant  ] 


In  DDL-P,  registers  are  storage  elements  which  may  be 
written  either  synchronously  or  asynchronously.  The  timing 
of  synchronous  vs.  asynchronous  stores  is  covered  in  chap- 
ters 7 and  8. 
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All  registers  are  declared  in  • list  iollouing  t h • key- 
uord  'REGISTER'  and  terminated  by  period  A register 

may  be  a single  flip-flop.  or  it  mey  be  e one-  or  two-dimen- 
sional array  of  flip-flops. 

Example 

REGISTER  V.C.N.Z.Rl 0:7. 1 5 > 0 I. 

XI  10:  1.5:  10  1 . Y ( 200:  100  I. 

In  the  above  example.  V.  C.  N.  and  Z are  each  declared 
to  be  unsubscripted  single-bit  registers.  Register  R is  a 
two-dimensional  array  oi  bits  logically  organized  as  eight 
16-bit  words.  The  bits  in  each  word  are  labeled 

1 5 . 1 4 , 1 3 . . . . . 1 . 0 . Bit  IS  is  the  most  significant  bit  (MSB). 
The  16-bit  words  of  R are  labeled  0 through  7. 


The  declarations  of  X and  Y in  the  example  illustrate 
two  points: 

1.  The  subscript  range  need  not  begin  or  end  with  0 
or  1 . 


2.  The  subscript  range  may  be  either  ascending  (5:10) 
or  descending  (200:100).  Note  that  in  register  X. 
the  MSB  of  each  word  is  bit  5.  while  in  register 
Y,  the  MSB  is  bit  200. 
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■ 

The  first  number  and  colon  * t*  may  be  omitted  from  a 
subscript  range,  in  which  case  a bound  of  one  is  assumed. 

Example 

"same  as  ' ARRAY! 1 : 1 0 , 1 : 20 1 ' " 

REGISTER  ARRAY!  10,20  1. 

* 

4.1.1  State  Sequencing  Registers 

A state  sequencing  register  may  be  used  to  encode  the 
states  of  the  finite  state  machine  defined  in  the  CONTROL 
section.  A state  sequencing  register  is  declared  by  immedi- 
ately preceding  the  identifier  by  '*'  in  the  REGISTER  decla- 
rations. It  may  not  have  two  dimensions. 

. Example 

REGISTER  A, B.tSSRl 3: 0 1 ,C. 

Up  to  seven  state  sequencing  registers  may  be  declared.  The 
use  of  state  sequencing  registers  is  discussed  in  chapter  8. 
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Chapter  5 

BOOLEAN  EXPRESSIONS  AND  OPERATORS 

In  DDL-P>  a Boolean  expression  is  a string  oi  one  or 
■ore  bits  formed  by  zero  or  more  operations  on  registers, 
memories,  terminals,  and/or  constants.  (Terminals  are  dis- 
cussed in  the  next  chapter.) 

First.  the  syntax  for  specifying  the  operands  is  pre- 
sented. Then  the  operators  will  be  discussed. 


term  : : > reference 

I I NPUT ( cons t an t . i d ent i f i er_r ef 

{ . identi f ier_ref } »**) 

I CASE  boolean_exp  DO  boolean_exp 

DO  boolean_exp 

( DO  boolean_exp  }***  ENDCASE 
I tboolean_exp*  boolean_exp  ; boolean_exp 

{{  boolean_exp) #**  . 
I IF  boolean_exp  THEN  boolean_exp 

ELSE  boolean_exp  END  I F 

I constant 
I ( boolean_exp  ) 


reference  :s»  identifier  ref  I terminal  ref 


An  operand  to  which  an  operator  is  applied  in  a Boolean 
expression  may  be  an  identifier  reference,  a terminal  refer- 
ence, an  INPUT  function,  a conditional  expression,  a Boolean 
expression  enclosed  in  parentheses,  or  a constant. 

5.1.1  Identifier  fL&lere.nces 


field  boolean_exp  : bool ean_exp 

identi f i er_ref  : = identifier 


identifier 
identifier 
identi f ier 

identi f ier 
identifier 
identi f ier 
identi f i er 
identifier 
ident i f ier 


I d ec 1 ma 1 _c ons t an t 
boolean_exp  ] 

I d ec l ma l_c ons t an t 

l boolean_exp 
boolean_exp  ) [ boolean_exp 
boolean_exp  , boolean_exp  1 
field  ] 

I d ec i ma 1 _c ons t an t [ field  ] 
boolean_exp  I I field  J 
bool ean_exp  , field  ] 


An  identifier  reference  is  a reference  to  one  or  more 
contiguous  bits  in  a facility,  where  a 'facility'  is  a re- 
gister, memory,  or  terminal.  The  bits  referenced  may  be 
specified  by  subscripts  (Boolean  expressions  enclosed  in 
brackets)  following  the  facility  identifier.  The  allowed 
kinds  of  subscripting  operations  are  illustrated  by  example 
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below . 


The  examples  assum^'the  following  declaration: 
MEMORY  ZERO,  ONE!  16:1],  TWO!  1 6 , 0 : 3 1 J . 


Examples  of  valid  references: 

ZERO 

Reference  to  the  bit  named  ’ZERO'.  This  is  the 
only  allowable  type  of  reference  to  ZERO;  ZERO  may 
not  be  subscripted. 


ONE  I 7 ] 

Reference  to  the  bit  labeled  7 in  the  facility 
ONE.  Note  that  7 is  in  the  allowed  range  16:1; 
ONEI20]  would  be  an  invalid  reference,  by  con- 
trast . 

ONE!  10:6  ] 

Reference  to  the  string  of  five  bits  ONE!  10] 
through  ONEI6]  inclusive.  The  order  of  the  ex- 
presssions  in  the  field  (increasing  or  decreasing) 
must  be  the  same  as  in  the  declaration;  e.g., 
ONE[6:10]  is  an  invalid  reference. 

ONE 

Reference  to  the  entire  facility  ONE;  equivalent 
to  ONE! 16:1]. 

TWO! 8, 17 ] 

Reference  to  the  bit  labeled  17  in  the  word  la- 
beled 8 in  the  facility  TWO. 

TWO l 8 ] l 17] 

Equivalent  to  TW0I8,171. 

TWO! 4, 16:231 

Reference  to  the  string  of  eight  bits  TWO[4,16] 
through  TWO(4,23]  inclusive. 
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TWO  14  11  16  > 23  ] 

Equivalent  to  TMOl 4 , 1 6 : 23  1 . 

TWO l 151 

Reference  to  the  entire  word  labeled  IS  in  facil- 
ity TWO;  equivalent  to  TWOl 1 5 , 0 : 3 1 ) . 


The  above  examples  show  all  valid  kinds  of  subscripting 
operations.  In  particular,  note  that  in  a Boolean  expres- 
sion, the  identifer  for  a two-dimensional  facility  must  be 
followed  by  at  least  one  subscript,  and  this  first  subscript 
must  not  be  a field. 

In  the  above  examples,  all  subscripts  were  constants. 
In  general,  however,  a subscript  may  be  any  valid  Boolean 
expression. 


When  the  first  subscript  following  an  identifier  is  a 
constant,  then  in  some  cases  the  subscript,  expressed  in  de- 
cimal, may  be  concatenated  to  the  identifier  without  being 
enclosed  in  brackets.  For  example,  'ID(nJ*  may  be  written 
as  'IDn',  where  'n'  denotes  a decimal  constant.  This  fea- 
ture is  designed  to  reduce  the  need  for  brackets  in  compli- 
cated Boolean  expressions.  Its  use  is  subject  to  two  res- 
trictions : 
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1.  The  identifier  name  'ID'  must  not  and  with  a deci- 
mal digit.  Hanca.  ' CX312)’  cannot  ba  urittan  as 
* EX32 ' . 

2.  Tha  id antiliar  ’IDn'  mutt  not  have  baan  daclarad. 
That  is,  ’EXAMPLES’  does  HOT  mean  'EXAMPLE[51'  ii 
'EXAMPLES’  is  itseli  a declared  identifier. 

Examples  (assuming  restrictions  satisfied) 
Reference  Equivalent  to 


ON  E8 

TWO  lit  31  J 
TWO  1 6 t A i B ) 


ONE [ 8 ) 

TWOt  11,31] 
TWOt  1 6 , A : B ] 
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DDL-P  may  apply  subscript  concatenation  in  unexpected 
places.  For  example,  an  identifier  'L3'  cannot  be  declared 
if  the  identifier  *L'  was  previously  declared.  A good  rule 
is  to  not  declare  identifiers  of  the  form  ’IDn’  (’n’*decimal 
constant,  ’ID’  ends  in  letter)  if  ’ID*  uill  also  be  dec- 
lared . 


5.1.2  .Terminal  Kei-sr-ensea. 


terminal_ref  identifier  ( boolean_exp 

t,  boolean_exp) ***  ) 


Most  facility  references  are  of  the  forms  described  in 


s 


the  above  section.  The  exception  is  the  special  case  of  a 
terminal  reference  with  an  actual-parameter  list.  The  ac- 
tual parameters  supplied  in  such  a terminal  reference  are 
inputs  to  the  combinational  network  represented  by  the  ter- 
minal. These  parameters  may  be  arbitrary  Boolean  expres- 
sions. (Recall  that  an  uns ubsc r i p t ed  two-dimensional  facil- 
ity name  is  NOT  a valid  Boolean  expression*  however.) 

Examples 

SUn(X(  11:16]*  1 6 D 2 ) 

PRODUCT ( 7 , X ) 

Note  that  a terminal  reference  with  a parameter  list  may  not 
be  subscripted.  Terminals  are  discussed  in  Chapter  6. 


5.1.3  IHP-UJ  Function 

The  INPUT  function  is  an  action  discussed  in  Chapter  7. 
In  short.  it  allows  for  the  setting  of  facilities  by  the 
user  from  the  teletype  at  s imu 1 a t i on- 1 ime . When  an  INPUT 
action  appears  as  a function  in  a Boolean  expression*  then 
the  function  receives  as  its  value  the  last  number  entered 
by  the  user. 
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Tor  example,  if  the  user  inputs  the  value  16D2  for  IN- 
CREMENT in  the  expression  R(+) INPUT! 1 , INCREMENT) . then  the 
expression  is  equivalent  to  R(+)2. 

5.1.4  Conditional  Expressions 

In  a conditional  expression)  a selector  expression  ap- 
pears along  with  at  least  tuo  alternative  expressions.  Ac- 
cording to  the  value  of  the  selector  expression.  one  of  the 
alternative  expressions  is  evaluated  and  used  as  the  value 
of  the  conditional  expression.  A conditional  expression 

CASE  select  DO  expr  1 
DO  expr  2 
• • • 

DO  expr  n-1 
DO  expr  n ENDCASE 

is  evaluated  by 

if  select" 1 then  expression  value  » expr  1 
else  if  selects  then  expression  value  = expr  2 
else  . . . 

else  if  select»n-1  then  expression  value  * expr  n-1 
else  expression  value  » expr  n. 

Note  that  expression  n above  is  chosen  for  select»0  and 
for  select>*n.  Conditional  expressions  may  be  nested. 

Tuo  other  forms  of  the  conditional  expression  are  al- 
lowed. The  above  conditional  expression  may  alternately  be 
written 
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♦ select  * expr  1 ; 

expr  2 j 

• • • 

expr  n-1  j 
expr  n . 

(with  period  ternineting  the  expression).  This  notetion  hes 

the  advantage  o!  being  compact.  A conditional  expression 

with  just  two  cases  may  be  written 

IF  select  THEN  expr  1 

ELSE  expr  2 ENDIF 

5.1.5  SI  her.  Bos lean  EHPreaaion  S Ear  a ad.  i 

An  arbitrarily  complex  Boolean  expression  enclosed  in 
parentheses  may  itself  be  an  operand  in  another  Boolean  ex- 
pression. The  enclosing  parentheses  may  be  omitted.  in 
which  case  the  order  in  which  operators  are  applied  is  det- 
ermined by  operator  precedence. 

Constants  may  also  appear  as  operands  in  Boolean  ex- 
pr ess i ons . 
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boolean_exp  :s  = minterm  { + minterm  }*** 

minterm  :s»  product  { l+l  product  )*»» 

product  >:■  complement  { * complement  }*** 

complement  {-}  reduction  { CON  reduction  1 »** 

reduction  adjustment 

I + RED  adjustment 
I * RED  adjustment 
I l+l  RED  adjustment 
t (+)  RED  adjustment 

adjustment  relation 

I adjustment  EXT  ar i thmet ic_exp 
I adjustment  TAIL  ari thmet ic_exp 
I adjustment  HEAD  arithmetic_exp 

relation  : * arithmetic_exp 

I arithmetic_exp  ( * ) ari thmet ic_exp 
1 arithmetic_exp  # ari thmet ic_exp 
I a r i thmet ic_exp  < a r i t hme t i c_ex p 
I arithmetic_exp  > ari thmet ic_exp 
I arithmetic_exp  >*  a r i t hmet ic_exp 
I ari thmet ic_exp  <*  ari thmet ic_exp 

ari thmet ic_exp  s:-  { (-)  } term 


I arithmetic_exp  (♦)  term 
I a r i thmet ic_exp  (-)  term 


The  syntax  oi  Boolean  expressions  defines  a precedence 
of  operators.  Operators  with  higher  precedence  are  applied 
before  operators  with  lower  precedence  unless  a different 
order  is  specified  with  parentheses.  Operators  of  the  same; 
precedence  in  an  expression  are  applied  left  to  right!  e.g., 
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A EXT  B TAIL  C HEAD  D 


is  squivslsnt  to 

<<A  EXT  B)  TAIL  C)  HEAD  D 

Ths  operators  sra  listed  below  in  order  of  precedence, 
highest  to  lowest.  All  operstors  on  the  same  line  have  the 
same  precedence.  The  reduction  (RED)  operstors  and  * - ' ere 
unary  operators.  The  •(-)•  operator  may  ba  either  unary  or 


binary.  The 

remaining 

operators  are 

binary 

<♦> 

( - ) 

(•) 

• 

< > 

<■ 

EXT 

TAIL 

HEAD 

♦ RED 

* RED 

!♦)  RED  (♦> 

RED 

COH 

a 

(♦1 

♦ 


5.3  aPXRATQRS 

The  operators  era  discussed  in  order  of  decreasing 
precedence,  except  for  the  reduction  operators,  which  are 
discussed  last.  Recall  that  a Boolean  expression  has  two 
attributes.  its  length  in  bits  and  its  value.  Henri.  for 
each  operator,  the  length  of  the  result,  as  well  as  its  va- 
lue. must  be  defined.  A warning  on  the  detection  of  nega- 


tive results  from  subtraction  appears  at  the  end  of  this 

m AM  4 t MM 


In  the  examples  below*  the  operators  are  used  with  con- 


stant operands.  However,  operands  can  be  quite  general,  as 
discussed  above  in  OPERANDS  IN  BOOLEAN  EXPRESSIONS . 

5.3.1  Arithmetic  Operators 

The  arithmetic  addition  operator  is  "(♦>".  The  two 
operands  in  an  addition  are  considered  to  be  non-negative 
binary  numbers  generating  a non-negative  sum.  II  one  ope- 
rand is  shorter  than  the  other.  the  shorter  operand  is  ex- 
tended on  the  left  with  zeroes  beiore  the  addition.  The 
length  ol  the  result  is  the  length  oi  the  longer  operand 
plus  one,  where  the  extra  bit  on  the  left  is  the  carry  out. 

Examples 

1B1  (♦>  4B101  1 > 5B01100 

4B11  11  < + ) 4B1  1 11  ■ 5B1  1 1 10 

1 B 1 ( + ) 1 B 0 ■ 2B01 

The  arithmetic  subtraction  operator  is  As  with 

addition,  the  two  operands  in  a subtraction  are  considered 
to  be  non-negative  binary  numbers,  the  operands  need  not  be 
the  same  length,  and  the  length  ol  the  result  is  the  length 
oi  the  longer  operand  plus  one.  However,  the  result  oi  a 
subtraction  is  a two's  complement  signed  binary  number,  with 
a one  in  the  carry  out  denoting  a negative  result. 
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The  operator  nay  also  be  used  for  unary  tuo'i 
complement  negation*  in  which  case  the  result  length  is  the 
same  as  that  of  the  operand. 


Examples 

1 B 1 (-)  4B1011 
4B  1 1 11  (-)  4B  1 1 1 1 
1 B 1 (-)  1 B 0 
1 BO  (-)  3B110 
(-)  3B110 
(-)  3B001 


■ 5B10110 

■ 5B00000 
- 2 B 0 1 

« 4B1010 
3 3B010 
3 3B1  11 


5.3.2 


In  relational  operations*  the  two  operands  are  consid- 
ered to  be  non-negative  binary  numbers.  The  result  of  the 
operations  is  1B1  if  the  indicated  relation  is  true  and  1B0 
otherwise.  The  two  operands  need  not  be  the  same  length. 


The  relations  denoted  by  the  operators  are  as  follow: 

(*)  equal  to 

• not  equal  to 

< less  than 

> greater  than 

<s  less  than  or  equal  to 

>3  greater  than  or  equal  to 


Examples 


2B 1 0 > 16D1 
1 0 D 1 * 1 B 1 
8 D 2 (-)  8D3 
1 B 1 >3  283 


* 1 B 1 
3 1 BO 
3 1 BO 
3 1 B 0 
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s.3.3  Subitrinp  pRinlgn 


The  operators  "EXT".  "TAIL",  and  "HEAD"  access  parts  oi 
the  first  operand  or  replicate  the  first  operand  as  indi- 
cated by  the  count  given  as  the  second  operand.  The  opera- 
tion "ARC  EXT  n"  concatenates  ARG  with  itself  n-1  times. 
The  operations  M ARG  HEAD  n"  and  "ARG  TAIL  n"  yield  the  most 
significant  (leftmost)  n bits  of  ARG  and  the  least  signifi- 
cant n bits  of  ARG.  respectively.  A run-time  error  occurs 
if  the  length  of  an  EXT  operation  result  exceeds  256  bits, 
or  if  the  number  of  bits  specified  in  a HEAD  or  TAIL  opera- 
tion is  greater  than  the  length  of  the  first  operand. 

Examples 

3 B 1 0 1 EXT  3 « 98101101101 

8B1  1010110  HEAD  4 » 4B 1 101 

8B1  10101  10  TAIL  2 > 2B10 

5.3.4  Concatenation 

The  "CON"  operator  concatenates  its  tuo  operands.  The 
left  operand  becomes  the  most  significant  (leftmost)  portion 
of  the  result.  A run-time  error  occurs  if  the  result  is 
longer  than  256  bits. 

Examples 

4B1101  CON  6B1  ■ 10B1 101000001 

4B1  CON  6B.1  « 10B000  1 1 00000 


5.3.5  One’s  Compltnent 


The  one's  complement  operator  complements  each  bit 

ol  the  operand.  The  length  of  the  result  is  the  same  as 
that  oi  the  operand. 

Exampl es 

- 1 B 1 « 1 B 0 

- 6 B 1 10101  = 6 B 0 0 1 0 1 0 

- 1091473  = 10B001 1000100 


5.3.6  a_inflry  L-acical  Operators 

A binary  logical  operator  performs  the  indicated  bit- 
wise logical  function  on  its  two  operands.  If  the  tuo  ope- 
rands are  of  differing  lengths.  then  a run-time  warning  is 
issued  and  the  shorter  operand  is  extended  with  zeroes  be- 
fore the  operation.  The  length  of  the  result  is  the  same  as 
that  of  the  longer  operand. 


The  functions  denoted  by  the  operators  are  as  follow: 


* Logical  AND  (highest  precedence) 

I + 1 Exclusive  OR 

+ Inclusive  OR  (lowest  precedence) 


Examples 


5B10110  * 5B00101 

5B101 10  l + J 5B00101 
5B10110  + 5B00101 

5B101 10  » 7B1  1 1 1 1 1 1 


5B00100 
5B1001  1 
5 B 1 0 1 1 1 

7B00101  10  with  warning 
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5.3.7  Reduction  Operators 

Using  the  bits  of  its  single  operand  as  arguments.  a 
reduction  operator  performs  the  indicated  operation  n-1 
times,  where  n is  the  length  of  the  operand.  For  example, 

[ + ] RED  ARC l 1:4] 
is  equivalent  to 

AR6 1 1+]  ARG2  [+1  ARG3  [+1  ARG4 
where  ARG  is  singly  dimensioned.  The  result  is  a single 
bit,  except  in  the  case  of  addition,  where  the  result  has 
length  16. 

Examples 

+ RED  5B00010  = 1B1 

* RED  5B1  1 1 1 1 = 1 B 1 

I + ] RED  5B00101  = 1 B 0 

( + ) RED  5B11101  = 16BOOOOOOOOOOOO0 100 

5.3.8  HaxiLLgg.  an  llg-g  si  SMblrag.tig.ti 

As  noted  earlier,  the  result  of  a subtraction  is  a 
two's  complement  signed  binary  number.  However,  the  other 
arithmetic  and  relational  operators  always  consider  their 
operands  to  be  unsigned  non-negative  numbers.  Hence  the  ex- 
pression 

A (-)  B < 0 
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does  not  perform  the  desired  function  of  detecting  a nega- 
tive result.  In  fact*  the  expression  alua/s  evaluates  as 
1B0,  since  no  unsigned  number  is  less  than  zero.  A simple 
expression  performing  the  desired  function  in  this  case  is 
A (-)  B HEAD  1 
or  even  simpler. 

A < B 

In  general,  care  is  required  uhen  using  arithmetic  or 
relational  operators  with  negative  numbers. 


Chapter  6 


TERMINAL  DECLARATIONS 


terminal_dec 1 

::=  TERMINAL  terminal_spec 

{ > terminal_spec  }***  . 

terminal_spec 

::=  identifier 

{ [ {constant:}  constant  ] } 

1 

identifier  [ {constant:}  constant  , 
{constant:}  constant  ] 

1 

identifier 

{ (identifier  {.identifier}***  ) } 

{ [{constant:}  constant]  } 

= boolean_exp 

Terminal  identifiers  are  names  for  the  outputs  of  com- 
binational networks*  called  'terminals'  in  DDL-P.  All  ter- 
minals are  declared  in  a list  following  the  keyword 
'TERMINAL*  and  terminated  by  period 

It  is  convenient  to  consider  a combinational  network  in 
three  parts: 

1.  OUTPUTS 
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2.  INPUTS  - Constants,  registers,  memories,  and  other 
terminals 

3.  FUNCTION  - Logical  function  (combinational  circui- 
try) mapping  inputs  to  the  outputs 

Uhen  a terminal  is  declared,  the  function  mapping  the  inputs 
to  the  outputs  may  or  may  not  be  given.  If  the  function  is 
given,  then  the  inputs  themselves  may  be  completely  speci- 
fied, or  some  inputs  may  be  left  unspecified;  the  unspeci- 
fied inputs  will  be  given  later  via  a parameter  list. 

In  general,  terminals  may  be  one-dimensional.  Some 
terminals  may  also  be  tuo-d imens i one  1 . The  syntax  for  spe- 
cifying terminal  dimensions  is  identical  to  that  for  giving 
the  dimensions  of  registers  or  memories. 


XERtllHAUS  UIXH 


In  the  simplest  case,  terminals  are  declared  without 
giving  the  associated  functions.  Such  terminals  may  be 
singly  or  doubly  subscripted. 

Example 


TERMINAL  A,B.C, 

DM0  1. 

T l 5 » 1 6 1 , S t 7 i 0 


"one  bit  each" 
"equivalent  to  DM  i 101" 
15.41. 
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The  values  or  functions  to  ba  associated  with  these 
terminals  may  be  specified  in  the  OPERATION  or  CONTROL  sec- 
tion. This  will  be  discussed  in  chapters  7 and  8. 

6.2  lEBlUHALS  HUH  SPEC-IflEP  FUNCTIONS  A2UB.  INPUTS 

The  function  associated  with  a terminal  may  be  speci- 
fied with  a Boolean  expression  in  the  declaration.  Termi- 
nals so  defined  may  be  singly-subscripted . 

Example 

TERMINAL  SUMXYl1t16)»  X ( ♦ ) Y TAIL  16, 

YL17-  SCORE<  1 7 , 

NEXTQ-  CASE  J CON  K DO  1 B 0 

DO  1 B 1 
DO  -Q 

DO  Q ENDCASE  , 

ONEl 1 « 8 1 ■ 8B 0000000  1 . 

Any  terminals  referenced  in  Boolean  expressions  in  TERMINAL 
declarations  must  be  declared  prior  to  their  appearance  in 
the  Boolean  expressions. 


6.3  .lE&niHAfcS  Him  UNSPECIFIED  INPUTS 

When  a terminal  function  is  specified  in  the  terminal 
declaration,  soma  or  all  of  the  inputs  may  not  be  identi- 
fied. These  inputs  are  represented  by  formal  parameters  in 
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the  declaration!  uhara  tha  formal  parameters  appear  in  a 
list  following  the  terminal  identifier.  Whenever  such  a 
terminal  is  referenced!  the  unspecified  inputs  must  then  be 
supplied  in  an  actual-parameter  list.  A terminal  with  a 
formal  parameter  list  may  be  singly  subscripted. 

Exampl e 

TERMINAL  SUM ( X , Y > l 1 « 1 2 1 • UODO  CON  XC+)Y)  TAIL  12. 

In  this  example!  inputs  X and  Y are  unspecified.  A 
valid  reference  to  SUM  might  then  be 

SUMtlRl 21 :32 J.Rt I R t 17:20  1 1) 

where  IR  and  R are  registers.  The  formal  parameters  are  as- 
sumed to  be  Boolean  expressions!  but  no  assumption  is  made 
regarding  the  lengths  of  the  parameters. 

Parameter  passing  is  by  value.  The  following  restric- 
tions applyt 

1.  Formal  parameters  may  not  be  subscripted.  A sub- 
scripting operation  may  be  simulated  with  HEAD  and 
TAIL!  although  this  is  less  efficient  than  normal 
subscripting . 

2.  A formal  parameter  may  not  appear  in  the  INPUT 
function. 
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Chapter  7 


) 


OPERATION  SECTION 

As  used  in  this  chapter*  the  term  "operation"  refers  to 
a named  sequence  of  actions.  where  actions  may  specify  data 
transfers,  sequencing  or  timing  information.  or  other  (pre- 
viously defined)  operations  to  be  invoked.  These  named  se- 
quences of  actions  are  defined  in  the  operations  section. 

The  several  possible  actions  are  presented  first.  fol- 
lowed by  a discussion  of  operation  definitions. 


I 
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7.1  ftfERAIIQH  ACTIONS 


action  * t ■ 

ident i f i er_ref  {CON  ident i f i er_r ef } 

<-  boolean_exp 

1 

ident i f i er_ref  {CON  ident i f i er_ref } 

* boolean_exp 

1 

identi f ier_ref  a 

1 

INPUT  ( constant  , ident i f ier_ref 

{ . ident i f i er_ref  }»»*  ) 

1 

OUTPUT  ( constant  , reference 

{ . reference  )**»  ) 

1 

identifier  { ( boolean_exp 

{ , boolean_exp  )»•*  ) } 

» 

CASE  boolean_exp 

DO  action  { , action  }*»» 

{ DO  action  { , action  }»*«  }#«»  ENDCASE 

1 

♦boolean_exp* 

action  { > action  }»** 

{ s action  { , action  }»«*  }««*  . 

1 

IF  boolean.exp 

THEN  action  { , action  }*«• 

{ ELSE  action  { , action  }**«  } ENDIF 

1 

TIME  boolean_exp 

1 

->  identifier 

1 

identifier  : action 

7.1.1  IntnLfidiat.e  .and  Delayed  Stores 

The  store  actions  and  w<-n  indicate  that  the  Boo- 
lean expression  on  the  right  hand  side  is  to  be  evaluated 
immediately  and  its  value  assigned  to  or  stored  in  the  fa- 
cility given  on  the  left  hand  side.  Two  facility  references 
®ey  he  concatenated  on  the  left  hand  side»  in  which  case  the 
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right  hand  facility  in  tha  concatenation  raoaivas  tha 
rightmost  bits  in  the  Boolean  expression,  and  tha  left  hand 
facility  gets  the  bits  to  the  left.  For  example. 

At  1:3)  CON  B t 1:5]  » 8B10101  100 
is  equivalent  to 

At  1:3]  * 3B101  , B ( 1:5]  > 5 B 0 1 100 

The  length  in  bits  of  the  facility  referenca(s)  on  the 
left  hand  side  should  be  the  same  as  the  length  of  the  Boo- 
lean expression  on  the  right  hand  side.  If  these  two 
lengths  differ,  then  a run-time  warning  is  issued.  If  the 
Boolean  expression  is  too  long,  then  high  order  (leftmost) 
bits  will  be  truncated  as  necessary.  If  the  Boolean  expres- 
sion is  too  short,  then  high  order  bits  of  the  destination 
facility  will  be  LEFT  UNCHANGED. 

The  evaluation  of  the  Boolean  expression  on  the  right 
occurs  exactly  once  (each  time  the  store  action  is  encoun- 
tered); any  subsequent  changes  to  operands  in  the  right  side 
do  not  cause  a re-evaluation  and  assignment.  Consider,  for 
example,  the  following  sequence  where  A,  B,  and  R are  sin- 
gle-bit flip-flops  and  T is  a terminal: 

[ R * 1 B 1 , 

T * R , 

A « T, 

R - 1 B 0 , 

B - T J 


The  assignment  of  1B0  to  R in  tha  fourth  line  does  not  causa 
a ra-avaluation  of  T.  Tha  value  assigned  to  B is  tha  same 
as  that  assignad  to  A,  namely  1B1.  Evan  though  terminals 
ware  described  in  Chapter  6 as  representing  combinational 
networks,  their  use  (as  above)  may  suggast  the  existence  of 
additional  sequential  circuitry.  if  indead  the  DDL-P  des- 
cription corresponds  closely  to  the  hardware  design. 


The  above  example  should  be  contrasted  with  the  follow- 
ing. in  which  A.  B.  R.  and  T ara  as  before,  but  the  function 
associated  with  T is  defined  in  the  TERMINAL  section: 

MEMORY  A,  B.  R. 

TERMINAL  T * R. 

OPERATION  EXAMPLE  - 
( R * 1 B 1 . 

A « T. 

R * t B 0 . 

B « T ]. 

In  this  case.  T is  re-evaluated  each  time  it  is  referenced 
in  the  operation.  Hence,  A is  set  to  1 B 1 , but  B is  set  to 
1 BO . 


This  illustrates  an  important  difference  between  the 
specification  of  a terminal  function  in  the  TERMINAL  section 
and  the  assignment  of  a function  to  a terminal  as  an  action 
in  an  operation.  Another  important  difference  is  that  an 
assignment  to  a terminal  made  in  an  operation  is  not  perman- 
ent. This  will  be  disoussed  further  in  the  next  chapter. 
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In  an  immediate  store,  danotad  by  "•*,  the  value  oi  tha 
right  hand  side  is  assigned  IMMEDIATELY  to  tha  facility  on 

I 

tha  left  hand  sida.  This  facility  may  ba  any  facility  ( re- 
gister* memory*  or  terminal)  EXCEPT  a state  sequencing  re- 
gister or  a terminal  for  which  a function  was  already  as- 
signed  in  the  TERMINAL  section. 

IExampl es 

T I 7 t 4 1 ■ 4D9  * 

MEM l R[ IRl 6:8  1 1 1 > Rl IRl 9:  11  ] ] 


7. 1.1.2  Delayed  Store 

In  a delayed  store*  denoted  by  "<-M*  the  right  hand 
side  is  evaluated  immediately*  but  the  resulting  value  is 
not  assigned  to  the  facility  until  the  end  of  the  current 
"state**.  Subsequent  references  to  the  left  hand  facility 
made  before  the  end  of  the  current  state  will  access  the 
old*  not  the  new*  value  of  the  facility. 

This  timing  will  be  discussed  further  in  the  next  chap- 
ter; for  now  it  will  suffice  to  understand  that  the  sequence 
of  actions 

A <-  B*  B <-  A 

I a 

S . 


will  effect  a swap  of  facilities  A and  B.  By  contrast*  the 
sequence 

A * B,  B - A 

will  not  effect  a swap,  but  is  equivalent  to  ”A=B"  alone. 

The  destination  in  a delayed  store  must  be  a register. 

Examples 

RtNiml  <-  MBR , 

ACC  <-  ALU ( ACC * Rl I 1 , 2) 

7.1.2  S.e_t-Jerjninal  Action 

DDL-P  provides  a shorthand  notation  for  an  immediate 
store  where  the  left  hand  side  is  a terminal  of  length  one 
bit  and  the  right  hand  side  is  IBt.  The  action 
T = 1B1 

may  be  written  as 
T a 

The  advantage  of  this  notation*  aside  from  its  brevity*  is 
that  it  may  also  appear  in  the  CONTROL  section  (Chapter  8), 
whereas  the  store  actions  and  may  not. 
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7.1.3  1XPUI  Aclion 


The  INPUT  action  allows  tha  user  to  enter  facility  va- 
lues from  the  teletype  at  simulation  time.  The  first  item 
in  the  list  enclosed  in  parentheses  is  a device  number, 
which  is  ignored  for  the  INPUT  action  in  the  current  imple- 
mentation of  DDL-P.  The  identifier  references  following  the 
device  number  indicate  the  facilities  to  be  input.  Any 
valid  identifier  reference  may  appear.  and  the  input  values 
are  stored  in  the  facilities  immediately. 

Examples 

INPUT ( 1 .ACC) , 

INPUT ( 1 ,Rt  11  .Tl L:R  1) 


The  values  entered  by  the  user  should  have  the  same 

a 

lengths  in  bits  as  the  corresponding  facilities  being  set. 
If  the  lengths  do  not  agree,  then  the  actions  taken  are  the 
same  as  those  for  a store  in  which  the  lengths  do  not  agree 
(Section  7.1.1). 

I 

The  user  will  be  prompted  for  new  values  each  time  the 
INPUT  action  is  encountered,  even  if  new  values  were  previ- 
ously supplied  during  the  current  operation.  Each  value  in- 
put  will  be  shown  in  the  listing  file. 

* 
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7.1.4  OUTPUT  Astlfln 


The  OUTPUT  action  immediately  lists  the  values  ol  the 
indicated  facilities  either  at  the  teletype  (if  device  num- 
ber is  zero  or  one)  or  in  the  listing  file  (if  device  number 
is  greater  than  one).  The  device  number  is  the  first  item 
in  the  OUTPUT  list;  the  remaining  references  indicate  the 
facilities  to  be  displayed.  Any  valid  facility  reference 
may  appear  in  this  list. 

Examples 

OUTPUT ( 1 » NUM,  RlNUPIl),  "To  teletype" 

OUTPUT ( 2 , MAR,  MEMlHAR),  MBR ) "To  listing  " 

7.1.5  Operation  Reference 


An  action  may  be  the  name  of  a previously  defined  oper- 
ation, in  which  case  the  sequence  of  actions  appearing  in 
that  definition  is  executed.  If  the  operation  was  defined 
with  formal  parameters  (Section  7.2),  then  a corresponding 
list  of  actual  parameters  (arbitrary  Boolean  expressions) 
must  be  supplied  enclosed  in  parentheses  following  the  oper- 
ation name. 

An  operation  may  invoke  itself  (recursion),  but  forward 
references  are  not  allowed. 


Examp  1 es 
INITIALISE. 

GETREG ( HUM . MEMl ADDR  ] ) 


7.1.6  Conditional  Action 

The  interpretation  of  conditional  actions  is  similar  to 
that  of  conditional  expressions.  A selector  expression  ap- 
pears along  with  one  or  more  lists  of  actions.  According  to 

the  value  of  the  selector  expression,  one  of  the  lists  will 

\ 

be  executed.  The  action 

CASE  selector  DO  list  of  actions  1 

DO  list  of  actions  2 

DO  list  of  actions  n-1 

DO  list  of  actions  n ENDCASE 

is  executed  as 

if  selector®!  then  list  of  actions  1 
else  if  selector=2  then  list  of  actions  2 
else  . . . 

else  if  selector=n-1  then  list  of  actions  n-1 
else  list  of  actions  n . 

The  alternative  forms  for  the  conditional  syntax  presented 
in  Section  5.1.4  may  also  be  used. 

A special  case  occurs  when  only  one  list  is  specified. 
In  this  case,  the  list  is  executed  only  ii  the  selector  has 
value  one;  otherwise,  the  entire  action  is  skipped.  A con- 
ditional action  with  just  one  list  may  be  written 
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IF  selector  THEN  list  oi  actions  END  I F 


Conditional  actions  may  be  nested. 

Examples 

IF  I >8  THEN  ACC<- 1 6D0 

ELSE  R( I ]<- 16D0  ENDIF  . 

IF  OVFL  THEN  PC  <-  EMA  ENDIF 
CASE  NA  DO  Ka  B 

DO  IF  FF  THEN  X«B  ELSE  Y«-B  ENDIF  ENDCASE 
The  last  example  may  also  be  uritten  using  the  alternate 
form  in  the  following  way: 

♦ NA  ♦ K*B  » ♦ FF  ♦ X»B  } Y«-B  . . 


7.1.7  Labels  and  Gotos 


Any  action  may  be  preceded  by  one  or  more  labels  (iden- 
tifiers^ each  followed  by  a colon.  The  course  cf  execution 
may  then  be  altered  with  a goto  " - > M . A goto  must  point  to 
a label  in  the  same  operation  definition.  Forward  referenc- 
ing of  labels  is  permitted. 

Labels  and  gotos  are  useful  for  specifying  loops  within 
operat i ons  . 


Example 


"Initialize  M[ lx  100, 15t0]  to  all  ones" 

ADDR  ■ 8D  1 , 

Li  M[ ADDR  ] - 16HFFFF, 

ADDR  » ADDR( + ) 1 TAIL  8. 

IF  ADDR  <*  100  THEN  ->L  ENDIF 

7.1.8  TIME  Specification 

The  designer  may  specify  that  a certain  action  or  oper- 
ation requires  T units  of  time*  where  T is  an  arbitrary  Boo- 
lean expression.  and  a "unit  of  time"  is  a convenient  unit 
selected  by  the  designer.  This  timing  is  specified  by  the 
action 

TIME  T 

The  default  length  of  time  assumed  is  use.  All  actions  in 
an  operation  are  considered  as  occurring  in  parallel,  so  the 
total  length  of  time  required  for  an  operation  will  be 
maximum  { times  required  for  each  action 
executed  in  the  operation  } 

A TIME  of  zero  should  not  be  given;  such  an  action  uill  be 
ignored . 


7.2  OPERATION 


opera t i on_d ec l «t*  OPERATION  operat i on_d ef 

{»  operat i on_def J ***  . 

operation_def  t:»  identifier 

( (identifier  {.identifier}***  ) } 
■ [ action  {,  action}***  1 


The  OPERATION  section  consists  of  a list  of  operation 
definitions.  The  list  is  preceded  by  "OPERATION"  and  fol- 
lowed by  period.  A simple  operation  definition  gives  the 
operation  name  followed  by  a list  of  actions  enclosed  in 
brackets.  The  actions  in  an  operation  must  form  a "compati- 
ble set  of  actions."  This  term  is  defined  in  Chapter  8;  ba- 
sically. it  denotes  a group  of  actions  in  which  illegal  sim- 
ultaneous stores  to  a register  do  not  occur. 


The  operation  name  may  optionally  be  followed  by  a for- 
mal parameter  list  enclosed  in  parentheses.  Uhen  such  an 
operation  is  referenced  later.  a corresponding  list  of  ac- 
tual parameters  must  be  supplied.  Parameter  passing  is  by 
value.  The  following  restrictions  apply  to  actual  and  for- 
mal parameters: 
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1.  Actual  parameters  must  be  valid  Boolean  expres- 
sions.  In  particular,  an  unsubscripted  two-dimen- 
sional facility  name  may  not  be  an  actual  parame- 
ter. 

2.  Formal  parameters  may  not  be  subscripted.  A sub- 
scripting operation  may  ba  simulated  with  HEAD  and 
TAIL.  although  this  is  less  efficient  than  normal 
subscripting . 

3.  No  assignment  of  a value  may  be  made  to  a formal 
parameter . 

<4.  Formal  parameters  may  not  appear  in  INPUT  or  OUT- 
PUT lists. 

Formal  parameter  names  are  declared  locally  to  the  operation 
definitions  the  names  may  be  re-declared  outside  the  opera- 
tion definition. 

Example 

OPERATION 

READ ( ADDR ) > l MBR«Mt ADDR  ) , 

Ml ADDR  )«8D0 , 

TIME  4), 

"ALU  is  assumed  to  be  s terminal" 

ARITH(FCT)  ■ [ ACC<- A LU ( FCT  ) ) . 

CLEAR! N ) ■ l IF  N>7  THEN  ACC<-8D0 

ELSE  REG l N ] < — 8 D 0 ENDIF  ], 

TTYINP  ■ l INPUT! 1 ,ACC>  ). 
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INIT  « l N«8D0, 

Li  REGIMJ-8D0, 

N-N(+)1  TAIL  8, 

IF  N<«7  THEM  ->L  EKDIF  . 
ACO8D0  ), 

DOFET  ■ ( ADDR- PC , PC<-PC(+)1  TAIL  16, 
READ ( ADDR ) J. 
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Chapter  8 


- 


i 


CONTROL  SECTION 

In  the  preceding  chapters*  we  have  seen  hou  to  define 
the  facilities  in  a system  (REGISTER*  MEMORY , and  TERMINAL 
declarations)  and  hou  to  specify  actions  which  may  occur 
within  the  system  (OPERATION  section).  Using  this  base*  we 
must  now  specify  the  overall  behavior  of  the  system.  In 
DOL-P  this  is  done  by  describing  the  system  as  a finite 
state  machine  in  the  CONTROL  sections. 

8.1  FINITE  STATE  BflCttlNE 


I level_decl  ss*  CONTROL  state_def  { state_def  }••• 

I 

state.def  i t»  (identifier  { (constant)  } :} 

I { state_action  {,  s tate_act ion} ***  } / 

I 

1 I 

In  general*  a DDL-P  description  may  have  more  than  one 
CONTROL  section.  These  sections  are  called  " i n t er pret i vel y 
linked  machines."  For  now*  however*  consider  the  case  where 
there  is  just  one  CONTROL  section*  or  level. 
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A finite  state  machine  consists  of  one  or  more  states. 
A state  is  an  abstract  expression  of  the  condition  of  the 
machine*  where  the  condition  may  be  as  simple  as  the  con- 
tents of  a register,  or  may  be  far  more  complex.  The  finite 
state  machine  is  in  one  state  at  any  given  time.  and  has 
rules  for  determining  the  outputs  and  the  next  state.  given 
the  current  state  and  the  inputs. 

Hence.  the  CONTROL  section  is  a list  of  state  defini- 
tions. where  each  state  has  up  to  three  parts: 

1.  Optional  label  (identifier)  naming  the  state. 

2.  Optional  constant,  enclosed  in  parentheses,  denot- 
ing the  value  which  should  be  in  the  state  se- 
quencing register  when  the  system  is  in  this 
state.  The  same  value  may  not  be  assigned  to  two 
different  states. 

3.  Optional  state  actions  for  determining  the  next 
state  and  the  values  of  facilities  when  the  system 
is  in  this  state. 

The  state  actions  are  separated  by  commas.  Each  state  de- 
finition is  terminated  by 
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2 HUE  STATE  ACTIONS 


state_action  : : * 

identifier  { (boolean_exp  { , boo  1 ean_ex p } *** ) > 

I idanti f ier_ref  8 
I ->  identifier 
I ■>  identifier 
I RETURN 

I CASE  boolean_exp 

DO  state_action  {.  * tate_act ion} »** 

{ DO  state_action  {,  *tate_act ion} ***  }«•» 
ENDCASE 

I iboolean_expi  state_action  { . s tate_act ion) »•» 

{ ; s tate_act ion 
{»  state_act ion} *»•  }»»*  . 

I IF  boolean_exp 

THEN  state^action  {,  s tate_act ion} »** 

{ ELSE  state^action  {.  s ta t e_ac t i on } »»*  } 
END  I F 

I LEVEL 


8.2.1 


LagiiitY  Values 


Two  state  actions  exist  for  modifying  facility  contents 
or  functions.  One  action  names  an  operation,  defined  in  the 
OPERATION  section,  to  be  executed.  The  syntax  and  semantics 
of  this  action  are  identical  to  those  for  the  operation  re- 
ference discussed  in  Section  7.1.5.  The  number  of  actual 
parameters  in  the  reference  must  match  the  number  of  formal 
parameters  in  the  definition. 


55 


The  second  action  is  the  set-terminal  action,  which  uas 


discussed  in  Section  7.1.2.  Its  syntax  is 
identi I ier_ref  9 ; 

it  denotes  that  the  named  one-bit  terminal  is  to  be  set  im- 
mediately to  1 B 1 . 

Examples 

"Operation  references" 

READ( ADDRl  1 : 16  ] ) , ARITH ( 4B  1 0 1 1 ) , 

CLEAR( 4 ) , TTYINP, 

"Set  terminals  to  1B1" 

T9,  BITS!  100,  121  9,  BUS [ 8 ] 9 


F 


8.2.2  Extermination  of  Next  state 

The  next  state  may  be  specified  explicitly,  implicitly, 
or  by  default.  Only  one  next  state  may  be  given  explicitly 
or  implicitly,  with  the  exception  that  two  next  states  may 
be  specified  if  exactly  one  of  them  uas  given  with  a su- 
broutine call  "=>". 

8.2.2. 1 Explicit  Next  State 

The  next  state  may  be  set  explicitly  by  any  of  three 
actions.  The  action 
->  STATE 
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8. 2. 2. 3 Default  Next  State 


If  the  next  state  is  not  specified  explicitly  or  impli- 
citly, then  by  default  the  next  state  is  the  state  following 
the  current  state  in  the  CONTROL  declaration.  Note  that  no 
default  exists  for  the  last  state  in  a CONTROL  declaration; 
in  the  last  state,  a next  state  must  be  specified  implicitly 
or  by  goto  "->"  or  "RETURN". 


8 . 2 . 2 . 4 Example 


The  following  example  illustrates  the  next-state  ac- 
t i ons  : 

REGISTER  tSSRl 2:01. 

OPERATION  SETSSR(N)  3 |SSR<-N  TAIL  31. 

CONTROL  PCI):  ->S/ 

Q(  2 ) : 3 >T/ 

R ( 3 ) : ->P,  3>U/ 

S C 4 ) : SETSSRC  2 ) , 3>V/ 

TC  5)  : / 

U ( 6 ) : SETSSRC  0 )/ 

V : 3>X/ 

UCO);  RETURN/ 

X C 7 ) : RETURN,  3>W/. 


State  sequence  for  this  example: 
System  starts  in  first  state,  P. 

# #» *»ST ATE=  P , SSR= 3D  1 , RETURN  STATE  STACK  IS  EMPTY. 

Next  state  is  S by  goto 


STATE»S,  SSR= 3D4 , RETURN  STATE  STACK  IS  EMPTY. 


II  "*>V"  were  missing.  then  "SETSSR(2)n  would  imply 
next  state  is  Q.  State  Q goes  on  return  state  stack.  and 
next  state  is  V.  State  V has  no  SSR  value  specified,  so  SSR 
is  left  equal  to  the  value  set  in  state  S.  If  state  V did 
have  an  SSR  value  given.  then  it  would  override  the  value 
supplied  in  state  S. 

#»**»STATE  = V,  SSR*  3D2 , RETURN  STATE  STACK  * Q. 


A nested  call.  If  "OX"  were  missing,  then  next  state 
would  be  U by  default. 

«»«»»STATE*X,  SSR* 3D7 , RETURN  STATE  STACK  = Q, U . 


If  "*>Un  were  missing.  then  next  state  would  be  U by 
RETURN.  State  14  is  popped  off  the  stack  by  RETURN,  but  then 
pushed  back  on  the  stack  by  "=>WW. 

»#*«»STATE*W,  SSR=3D0,  RETURN  STATE  STACK  = Q,W. 


Next  state  is  U by  RETURN. 

«»#»«STATEsM,  SSR* 3D0 , RETURN  STATE  STACK  * Q . 


Next  state  is  Q by  RETURN. 

»«»*«STATE*Q.  SSR*3D2,  RETURN  STATE  STACK  IS  EMPTY. 

If  ”*>T"  were  missing,  then  next  state  would  be  R by 
default . 

#»*#*STATE*T , SSR* 3 D5 , RETURN  STATE  STACK  * R. 

Next  state  is  U by  default. 

»»*»*STATE*U,  SSR*  3D6 , RETURN  STATE  STACK  * R. 

"SETSSR ( 0 ) " implies  next  state  is  W. 

«»«**STATE*U , SSR*  3D0 , RETURN  STATE  STACK  * R. 


Next  state  is  R by  RETURN 


»*»#»STATE=R.  SS  R=  3 D 3 » RETURN  STATE  STACK  IS  EMPTY. 


If  "»>U"  were  missing,  then  next  state  uould  be  P by 
goto  . 


*STATE=U,  SSR=  3D6 , RETURN  STATE  STACK  = P. 


"SETSSR(0)M  implies  next  state  is  W. 

##*»»STATE=U.  SSR=3D0 , RETURN  STATE  STACK  = P. 

Next  state  is  P by  RETURN.  This  completes  the  cycle. 
»**««STATE=P,  SSR- 3D  1 , RETURN  STATE  STACK  IS  EMPTY. 


8.2.3  £.t-her  State  Actions 

The  conditional  state  action  looks  and  behaves  like  the 
conditional  action  discussed  in  Section  7.1.6.  According  to 
the  value  of  a selector  expression,  one  of  several  lists  of 
actions  is  executed.  The  action 


CASE  selector  DO 

list 

of 

state 

act i ons 

1 

DO 

list 

of 

state 

act i ons 

2 

DO 

list 

of 

state 

actions 

n-  1 

DO 

list 

of 

state 

act i ons 

n 

ENDCASE 

is  executed  as 
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if  selector=1  then  list  of  state  actions  1 
else  if  selector=2  then  list  of  state  actions  2 
else  . . . 

else  if  selector=n-l  then  list  of  state  actions  n-1 
else  list  of  state  actions  n 


In  the  special  case  uhere  only  one  list  of  actions  is 
specified,  the  list  is  executed  only  if  the  selector  has  va- 
lue one;  otherwise,  the  entire  state  action  is  skipped. 
Conditional  state  actions  may  be  nested. 

Example 

IF  SCORE<  1 7 
THEM  ->B 

ELSE  IF  SCORE<22  THEN  ->JK 

ELSE  IF  FF  THEN  ->D  ENDIF, 

KFF , TMT 

ENDIF 

ENDIF 


The  last  state  action  is  LEVEL.  This  is  mentioned  here 
for  completeness  only.  LEVEL  will  be  discussed  in  Sec- 
tion 8.4. 


8.3  IIHIM  CONSIDERATIONS 

8.3.1  liming  Immediate  and  Delayed  Stores 


As  the  simulation  of  a state  is  carried  out,  store  or 
input  actions  may  be  encountered.  The  timing  for  such  ac- 
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tions  is  as  follows: 


1.  If  • store  action  ("■ 


or  "8")  is  encoun- 


ft 

9 > » 

tered,  the  right  hand  side  is  evaluated  immedi- 
ately. This  evaluation  occurs  just  once,  as  dis- 
cussed in  Section  7.1.1.  If  an  INPUT  action  is 
encountered,  the  input  value  is  requested  immedi- 
ately. 

2.  In  the  case  of  an  immediate  store  ( " = " or  "a")  or 
INPUT  action,  the  neu  value  is  stored  in  or  as- 
signed to  the  specified  facility  immediately.  In 
the  case  of  a delayed  store  to  a register  ("<-"), 
the  neu  value  is  not  stored  immediately,  but  is 
saved  in  a temporary  buffer. 

3.  At  the  end  of  the  state,  the  simulator  checks  to 
see  if  it  should  halt  the  simulation  or  do  any 
I/O.  This  occurs  BEFORE  the  neu  register  values 
specified  in  delayed  stores  are  stored.  Hence, 
any  register  values  accessed  or  output  by  the  si- 
mulator at  this  time  are  still  old  values. 

4.  When  the  simulation  continues,  the  neu  values 
given  in  delayed  stores  are  stored  in  the  regis- 
ters. At  the  same  time,  any  terminals  uhich  uere 
set  are  cleared  to  zero.  Hence,  any  assignment  to 
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• terminal  is  tsnporary  and  lasts  (at  most)  until 
tha  and  of  tha  currant  stata. 

5.  Aftar  tha  ragistars  hava  baan  updated  and  tha  ter- 
minals cleared#  tha  simulator  begins  simulation  of 
tha  next  stata. 


This  timing  is  illustrated  by  tha  following  example 
with  waveforms: 


Example 

REGISTER  A#B,R#S. 

MEMORY  M. 

TERMINAL  T. 

OPERATION 

SWAP  ■ ( A<-B » B<-Al. 

A I MM ( X ) ■ lA-X],  BIMM(X)  » IB-XJ, 

RIMM(X)  ■ IR«X), 

SIMMCX)  « [S»Xl.  SDEL(X)  « [ S<-X  ] , 

MIMM(X)  ■ ( M = X ] , 

TIMM(X)  « I T*X  ) . 

CONTROL 

INIT:  AIMMUBO),  BIMM(IBl),  RIMMUBO). 

SIMM(IBO),  MIMMC1B1),  TIMM(IBO),  ->P/ 
P : SWAP,  RIMM(IBI).  SDELMB1), 

MIMM(S),  T 3,  ->Q/ 

Q : MIMM(IBI),  ->Q/. 
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WAVEFORMS 


1 

A 

0 


1 

B 

0 


1 

R 

0 


1 

n 

o 


T 

0 

STATE  INIT  STATE  P STATE  Q 


Note  that  the  value  assigned  to  M in  state  P is 
1B0,  the  "old"  value  of  S,  even  though  the  delayed 
store  to  S has  already  been  encountered.  The  va- 
lue assigned  to  S is  stored  at  the  beginning  of 
state  Q.  Also.  terminal  T is  cleared  before  the 
start  of  state  Q.  Finally,  note  how  the  swapping 
of  values  of  A and  B occurs. 

During  the  simulation,  once  a delayed  store  to  a regis- 
ter is  specified,  any  further  stores  to  the  same  bits  during 


the  same  state  will  cause  a "SIMULTANEOUS  STORE"  warning 
message  to  be  issued  and  the  previously  specified  delayed 
store  canceled.  Such  an  error  indicates  an  illegal  attempt 
to  simultaneously  store  multiple  values  into  the  same  regis- 
ter. A set  of  actions  in  which  such  errors  d_2  not  occur  is 
called  a "compatible  set  of  actions." 

8.3.2  limina  ai.  Operations  anl  States 

All  the  operations  in  a state  are  considered  as  occur- 
ring in  parallel.  Furthermore*  all  the  actions  in  an  opera- 
tion occur  in  parallel.  Hence*  the  time  required  for  a 
state  is  just  the  time  required  for  the  longest  action  in- 
voked by  the  state.  This  time  is  one  by  default  and  may  be 
increased  by  the  TIME  action.  Note  that  the  times  required 
for  the  actions  in  a state  may  vary  widely*  but  ALL  the  ac- 
tions will  be  completed  before  the  system  moves  to  the  next 
state*  even  if  this  in  some  sense  implies  that  a large  por- 
tion of  the  system  is  "idle"  much  of  the  time. 

The  designer  may  specify  that  the  actions  in  a state 
occur  sequentially*  rather  than  in  parallel*  by  splitting 
the  state  into  a sequence  of  states.  This  idea  is  illus- 
trated in  the  example  below. 
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iNttkii 


Example 


REGISTER  A ( 101,  B [ 10].  OVERFLOW . 

MEMORY  MEMl  1024,  10  1 . 

OPERATION  ADD  * [OVERFLOW  CON  A <-  A(+)B], 

STORE  * [MEMlA]  <-  A.  TIME  21. 

In  the  above  specification,  one  unit  of  time  is  implied 
for  operation  ADD  while  two  units  of  time  are  specified  for 
STORE.  If  the  two  operations  are  executed  in  parallel  in 
one  state, 

ADD,  STORE/  , 

then  the  time  required  for  the  operations  is  two  units.  The 
designer  may  alternately  specify  that  ADD  and  STORE  art*  exe- 
cuted sequentially  by  breaking  the  state  into  a s>  < .nee  of 
two  states,  as  in 

ADD/  STORE/ 

This  sequence  will  take  three  units  of  time. 

Note  that  the  choice  of  parallel  vs.  sequential  execu- 
tion will  have  a marked  effect  on  system  operation.  In  the 
example  above,  suppose  that  A and  B originally  contained 
10D5  and  10D10,  respectively.  Then  in  the  first  case,  oper- 
ation STORE  accesses  the  old  value  of  A and  stores  10D5  in 
MEMl 5],  while  in  the  second  case,  STORE  accesses  the  new  va- 
lue of  A and  stores  10D15  in  MEMl 151. 
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The  technique  oi  splitting  states  can  be  used  in  the 
description  of  a system  with  a multi-phase  clock.  Each 

clock  cycle  may  be  specified  as  a sequence  of  states,  where 
each  state  represents  one  phase,  as  suggested  beloui 
CONTROL 

" PHASE  1 PHASE  2 ...  PHASE  I" 

STATEIj  ACTSH/  ACTS  1 2/  ...  / ACTS  1 1/ 

STATE2:  ACTS2 1/  ACTS22/  ...  / ACTS2 1/ 


• • • 

STATEHs  ACTSN 1/  ACTSN2/  ...  / ACTSNI/. 

Alternately,  a designer  may  describe  a system  with  a multi- 
phase clock  as  two  interpretively  linked  machines  (next  sec- 
tion); a state  in  the  higher  ’aval  machine  would  correspond 
to  one  clock  cycle,  while  a sta  in  the  lower  level  machine 
would  correspond  to  one  phase.  This  illustrates  the  freedom 
the  designer  has  in  choosing  the  level  of  detail  and  the 
significance  of  a "state"  in  a DDL-P  description. 


L.IMKEB  MACHINES 


control_decl  st«  level_decl  { level_decl  }**»  . 


In  general,  a DDL-P  description  may  have  several  (up  to 
seven)  CONTROL  sections.  Each  CONTROL  section  defines  a 
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complete  finite  stete  machine.  The  several  machines  have  a 
hierarchical  relationship;  the  first  machine  defined  is  at 
the  highest  or  top  level*  level  1.  The  succeeding  machines 
are  at  level  2*  level  3.  etc. 

The  higher  level  machines  are  typically  control  ma- 
chines uhich  set  terminals  serving  as  control  lines.  The 
lower  level  machines  test  these  terminals  and  "interpret" 
them*  executing  the  indicated  functions.  Hence*  the  ma- 
chines are  said  to  be  "interpretively  linked  machines." 

During  the  simulation*  control  must  pass  from  state  ma- 
chine to  state  machine  in  some  orderly  fashion.  The  LEVEL 
action  aids  in  this  process.  When  the  state  action 
LEVEL 

is  encountered  in  a machine*  then  control  uill  pass  to  the 
next  higher  level  machine  at  the  end  of  the  current  state* 
AFTER  the  new  values  of  registers  changed  at  this  level  have 
been  stored*  AFTER  terminals  set  at  this  level  have  been 
cleared*  and  BEFORE  simulation  of  the  next  state  at  this 
level  begins.  A LEVEL  in  the  top  level  machine  is  ignored. 

Conversely*  control  uill  pass  unconditionally  to  the 
next  lower  level  machine*  if  such  a level  exists*  at  the  end 
of  the  current  state*  AFTER  all  actions  in  the  current  state 
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have  bean  executed 


BEFORE  the  new  values  ot  registers 


changed  at  this  level  have  been  stored,  and  BEFORE  terminals 
set  at  this  level  have  been  cleared. 

Simulation  always  begins  in  the  level  1 machine.  By 
default,  the  very  first  state  to  be  executed  at  each  level 
will  be  the  first  state  in  the  corresponding  level  declara- 
tion, although  the  designer  may  specify  different  starting 
states  on  each  level  at  simulation  time.  The  simulation  of 
the  finite  state  machine  at  level  i (call  it  machine(i)) 
will  then  proceed  as  follows: 

1.  If  a higher  level  machine  exists  (if  i>1),  then 
machine(i-l)  passes  control  to  machine(i)  at  the 
end  of  a level  i- 1 state. 

2.  The  simulator  executes  the  actions  for  the  next 
state  in  machine(i)  (where  the  next  state  was  pre- 
viously determined).  It  completes  immediate 
stores  while  saving  delayed-store  values  as  dis- 
cussed in  Section  8.3.1.  The  simulator  also  det- 
ermines the  next  state  for  machine(i). 

3.  At  the  end  of  this  state  (but  BEFORE  register  va- 
lues are  stored),  machine(i)  passes  control  to  ma- 
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chine(i-frl).  If  there  is  no  such  machine.  then  the 
simulator  checks  to  see  if  it  should  halt  or  do 
any  I/O.  (These  actions  are  requested  by  the  de- 
signer at  simulation  time;  see  DDL-P  Command  Lan- 
guage Manual . ) Note  that  register  values  accessed 
by  lower  level  machines  will  not  reflect  changes 
by  delayed  stores  at  level-i  in  the  previous 
state,  the  new  values  not  yet  having  been  stored. 

k.  When  control  is  returned  to  machine(i)  from  ma- 
chine(i+1)  or  from  simulator  I/O  activity.  then 
machine(i)  stores  the  new  register  values  given  in 
the  previous  level-i  state.  also  clearing  termi- 
nals that  were  set  in  that  state. 

5.  If  a LEVEL  command  was  not  encountered  in  the  pre- 
vious level-i  state,  then  machine(i)  proceeds  with 
the  execution  of  the  next  level-i  state.  Other- 
wise. machine(i)  passes  control  to  machinet i- 1 ) . 

In  the  latter  case,  machine(i)  remembers  what  the 
next  level-i  state  will  be  when  control  is  re- 
turned from  machine( i- 1 ) . 

The  system  is  considered  as  being  in  one  state  in  each 
machine  at  any  given  time.  The  "total  state"  of  the  system 
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is  then  a list  oi  states.  with  ona  state  from  each  machine. 
An  example  oi  a three-level  control  declaration  is  given  be- 
low. followed  by  a description  of  the  simulation  of  state  A. 
The  simulation  begins  at  level  1 in  "total  state"  A:C:E. 


CONTROL 

A 8 

OPA, 

->B/ 

B 8 

OPB , 

->  A/ 

CONTROL 

C 8 

OPC, 

->D/ 

D 8 

OPD. 

->C,  LEVEL/ 

CONTROL 

E 8 

OPE, 

->F/ 

F 8 

OPF, 

LEVEL,  ->E/ 

Execution  of  State  A 


TOTAL  STATE 

A : C : E : Start  at  level  1 in  total  state  A.’CsE. 

A i C : E t Execute  OPA.  next  machine(l)  state  will  be  B. 
A : C : E : Drop  to  level  2. 


A s C : E : Execute  OPC.  next  machine(2)  state  will  be  D. 
A : C : E t Drop  to  level  3. 


A:C:E 
A : C : E 
A i C : E 
A i C : F 
A : C : F 
A s C : F 
A>C:E 


Execute  OPE.  next  machine(3)  state  will  be  F. 
Check  for  simulator  I/O  or  halt. 

Store  registers,  clear  terminals  from  OPE. 
Execute  OPF.  next  machine(3)  state  will  be  E. 
Check  for  simulator  I/O  or  halt. 

Store  registers,  clear  terminals  from  OPF. 
Rise  to  level  2. 


A : C : E : Store  registers,  clear  terminals  from  OPC. 

A > D : E > Execute  OPD.  next  machine(2)  state  will  be  C. 
A : D > E : Drop  to  level  3. 


A : D s E : 
A: D:E: 
A i D : E : 
A i D : F : 
A : D : F : 
A : D : F : 
A : D : E : 


Execute  OPE.  next  machine(3)  state  will  be  F. 
Check  for  simulator  I/O  or  halt. 

Store  registers,  clear  terminals  from  OPE. 
Execute  OPF.  next  machine(3)  state  will  be  E. 
Check  for  simulator  I/O  or  halt. 

Store  registers,  clear  terminals  from  OPF. 
Rise  to  level  2. 


A t D : E s Store  registers,  clear  terminals  from  OPD. 
A t C : E t Rise  to  level  1. 
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A'.C-.E:  Store  registers,  clear  terminals  iron  OPA, 

completing  simulation  of  state  A.  Simulation  of 
state  B will  proceed  in  similar  fashion. 

State  Sequencing  Registers . Each  finite  state  machine 
may  have  its  own  state  sequencing  register  (S.S.R.).  The 
first  S.S.R.  declared  is  associated  uith  the  highest  level 
machine,  the  second  S.S.R.  declared  is  associated  uith  the 
level-2  machine,  etc. 

Restrictions . The  following  restrictions  apply  in  the 
specification  of  multiple-level  control  declarations: 

1.  A finite  state  machine  should  not  modify  the  state 
sequencing  register  for  a lower  level  machine. 

Tor  example,  the  machine  at  level  2 should  not  mo- 
dify the  S.S.R.  for  level  3. 

2.  All  state  gotos  "->"  and  subroutine  calls  "*>" 
must  point  to  states  within  the  same  finite  state 
machine.  It  is  not  possible,  for  example,  to  use 
one  group  of  states  as  a subroutine  in  two  differ- 
ent finite  state  machines.  The  following  is  not 
permitted : 

CONTROL  A:  ->C/  "< — ERROR" 

B:  -> A/ 

CONTROL  C:  ->B/.  "< — ERROR" 
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13.  The  LEVEL  action  should  not  appear  in  a state 

which  is  in  a subroutine  or  which  contains  a su- 

I 

broutine  call  If  this  rule  is  violated,  un- 

predictable simulator  errors  may  occur. 


Chapter  9 


EXAMPLES 

Five  complete  DDL-P  descriptions  are  nou  presented  with 
briei  discussions. 

1 

The  iirst  machine  plays  Blackjack  by  dealer's  rules, 
accepting  cards  until  its  score  exceeds  16,  and  counting  the 
iirst  Ace  as  eleven  unless  that  causes  its  score  to  exceed 
21.  The  machine  shows  its  status  in  terminals  HIT,  STAND, 
and  BROKE.  Card  values  are  entered  through  terminal  VALUE, 
and  YCRD  is  a "card  ready"  strobe. 


Example  1 


"BLACKJACK  MACHINE." 
REGISTER  SCORE [ 5 1 » CARDBUF [ 5 1 , FF. 
TERMINAL  HIT , BROKE,  STAND, 

VALUE!  1:51  = INPUTd  .VALUE)  , 

YCRD  3 INPUT!  1 , YCRD  ) , 

YL 17  3 SCORE< 17,  YL22  3 SCORE<22, 

NACE  = CARDBUF#  1 . 

OPERATION 

TPT  3 I CARDBUF  <-  5D  1 0 J , 

TMT  = l CARDBUF  <-  5D22], 

T VC  = l CARDBUF  <-  VALUE], 

IHIT  3 I H I T=  1 B 1 ], 

I STD  3 I STAND3  1 B 1 ] , IBRK  = [BROKE=1Bl], 
CLS  = [ SCORE  <-  5D0  ] , 

ADD3 [ SCORE  <-(SCOREC+)CARDBUF)TAIL  5], 
KFF  3 [FFC-1D0],  JFF  3 [ FF  <-  1 D 1 ] 

CONTROL 

A:  CLS,  KFF,  ->B/ 

B:  IHIT,  TVC , 

IF  YCRD  THEN  ->C  ELSE  ->B  ENDIF/ 

C:  IF  YCRD  THEN  ->C  ELSE  ->D  ENDIF/ 

D:  ADD,  IF  NACE+FF  THEN  ->F 

ELSE  — >E  ENDIF/ 

E:  JFF,  TPT,  ->D/ 

F:  IF  Y L 1 7 THEN  ->B  ELSE  ->G  ENDIF/ 

G:  IF  YL  22  THEN  ->K  ELSE  ->H  ENDIF/ 

H;  KFF,  TMT, 

IF  FF  THEN  ->D  ELSE  ->J  ENDIF/ 

J:  IBRK, 

IF  YCRD  THEN  ->A  ELSE  ->J  ENDIF/ 

K:  I STD , 

IF  YCRD  THEN  ->A  ELSE  ->K  ENDIF/.# 


The  second  machine  is  identical  to  the  first  except 
that  states  F,  G,  H,  J,  and  K have  been  combined  into  tuo 
states,  F and  JK.  This  example  shows  nested  conditional 
state  actions,  and  also  suggests  the  flexibility  possible  in 
describing  a system  as  a finite  state  machine. 
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Example  2 


"BLACKJACK  MACHINE." 

REGISTER  SCORE ( 5 ] , CARDBUF [51*  FF. 

TERMINAL  HIT,  BROKE,  STAND, 

VALUE! 1:5]  * INPUT! 1 .VALUE) , 

YCRD  = INPUT!  1 , YCRD  ) , 

YL 1 7 * SC0REO7,  YL22  = SCORE<22, 

NACE  - CARDBUF#  1 . 

OPERATION 

TPT  * ( CARDBUF  <-  5D10  J, 

TMT  * [CARDBUF  <-  5D221, 

TVC  * [CARDBUF  <-  VALUEl, 

IHIT  - l HIT*  1B1  1 , 

I ST  D = [ STAND3  1 B 1 J , IBRK  * [ BROKE8 1 B 1 ] , 

CLS  = [ SCORE  <-  5 D 0 1 , 

ADD= [ SCORE  <-! SCORE!  + ) C A RDBUF  ) T A I L 5], 

KFF  = [ FF<-  IDO],  J FF  = [ FF  <-  1D1  ] 

CONTROL 

As  CLS,  KFF,  ->B/ 

B:  IHIT,  TVC,  IF  YCRD  THEN  ->C  ELSE  ->B  ENDIF/ 

C:  IF  YCRD  THEN  ->C  ELSE  ->D  END  I F/ 

D:  ADD,  IF  NACE  + FF  THEN  ->F  ELSE  ->E  END  I F/ 

E:  JFF , TPT,  ->D/ 

Fs  IF  YL  1 7 THEN  ->B 

ELSE  IF  YL22  THEN  ->JK 

ELSE  IF  FF  THEN  ->D  ENDIF, 
KFF,  TMT 

ENDIF  ENDIF/ 

JKi  IF  YL22  THEN  ISTD  ELSE  IBRK  ENDIF, 

IF  YCRD  THEN  ->A  ELSE  ->JK  ENDIF/.# 


The  third  machine  is  functionally  equivalent  to  the 
first  tuo,  but  its  state  is  encoded  in  a state  sequencing 
register  Q consisting  of  three  J-K  flip-flops.  The  charac- 
teristic functions  and  input  equations  for  register  Q are 
given  in  operation  NS.  The  next  state  in  this  machine  is 
then  implied  by  the  results  of  operation  NS. 
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Note  the  heavy  use  oi  subscript  concatenation  (e.g. 


"Q1")  in  operation  NS. 


Example  3 

"BLACKJACK  MACHINE." 

REGISTER  SCORE ( 5 ] > CARDBUF 15).  FF,  • Q( 3 : 1 ] . 
TERMINAL  HIT.  BROKE.  STAND,  TMP » 

Jl 3s  11*  K l 3 : 1 1 . 

VALUE!  1:5]  ■ INPUT(  1 .VALUE)  . 

YCRD  * INPUT!  1 . YCRD  ) . 

Y L 1 7 = SC0REO7,  YL22  3 SCORE<22. 

NACE  3 CARDBUF#  1 . 

OPERATION 

NS  3 (TMP  * YCRD, 

Jl3  -Q3*(FF+NACE)+-Q2»-Q3, 

K 1 3 Q2*-Q3*-TMP  + -Q2«Q3  + Q3«-YL 17»YL22 . 
Q1<-  CASE  Jl  CON  K 1 DO  IDO  DO  1D1 

DO  -Q 1 DO  Q 1 ENDCASE, 

J 2=  Q1#Q3*FF  + Q1*-Q3*TMP, 

K23  Q1*Q3, 

Q2<-  CASE  J 2 CON  K2  DO  IDO  DO  1 D 1 

DO  -Q2  DO  Q2  ENDCASE, 

J 3 3 -Q1#Q2, 

K33  J 3 + -Q1*TMP  + Q2*YL17  + Q1*-Q2«FF, 

Q3<-  CASE  J 3 CON  K3  DO  IDO  DO  1 D 1 

DO  -Q3  DO  Q3  ENDCASE], 

TPT  * (CARDBUF  <-  5D10  ], 

TMT  = (CARDBUF  <-  5D22], 

TVC  = (CARDBUF  <-  VALUE], 

IHIT  « I H I T » 1 B 1 ], 

I STD  * I STAND3  1 B 1 ] , IBRK  = [ BROKE3  1 B 1 ] , 

CLS  3 ( SCORE  <-  5D0  ] , 

ADD3(SCORE  <-(SCORE(+)CARDBUF)TAIL  5], 


KFF  ■ 

(FFC-1D0  ].  J FF  3 IFF  <- 

1 D 1 ] 

CONTROL 

A(0)  > 

CLS,  KFF.  NS/ 

B(  n : 

IHIT,  TVC,  NS/ 

0(1)  i 

NS/ 

D(  2)  : 

ADD,  NS/ 

E ( 6 ) : 

TPT.  JFF , NS/ 

FG ( 7 ) : 

NS/ 

H<  5)  : 

TMT.  KFF,  NS/ 

J K C 4 ) i 

IF  YL22  THEN  ISTD  ELSE 

IBRK  ENDIF, 
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The  fourth  example  has  tuo  finite  state  machines.  The 
top  level  machine  simply  sets  terminals  uhich  are  inter- 


preted by  the  lower  level  mac-hine.  On  receipt  of  a signal 
START.  the  system  computes  the  sum  of  the  256  words  of  MEM. 
Note  the  destruc4ive-read/restore  sequence  simulated  by  the 
lower  level  machine. 

Example  4 

" EXAMPLE  OF  I NTERPRETI VELY  LINKED  MACHINE  " 

REGISTER  A ( 16  1.  B [ 16],  ADDRl 8 ] . 

MEMORY  MEM ( 0 : 255.  161. 

TERMINAL  YCLR.  YINC,  YADD.  YREAD, 

NDONE  = A DDR  # 255, 

START  = INPUT  (1,  START). 

OPERATION  CLEAR  = [A  <-  16D0,  ADDR  <-  8D01, 

INC  = (ADDR  <-  ADDRC  + ) 8D 1 TAIL  8], 

ADD  = (A  <-  A ( + ) B TAIL  161, 

READ  = [B  <-  MEMlADDRl, 

MEM [ ADDR  1 - 16D0], 

RESTORE  = (MEMlADDRl  = Bl. 

CONTROL 

Pis  IF  START  THEN  YCLR  3,  YREAD  8,  ->P2 
ELSE  ->P1  ENDIF/ 

P 2 s YADD  8, 

IF  NDONE  THEN  YINC  8,  YREAD  8,  ->P2 
ELSE  ->P1  ENDIF/ 

CONTROL 

Q 1 s IF  YINC  THEN  INC  ENDIF, 

IF  YCLR  THEN  CLEAR  ENDIF, 

IF  YADD  THEN  ADD  ENDIF, 

IF  YREAD  THEN  ->Q2 

ELSE  ->Q 1 , LEVEL  ENDIF/ 

Q2:  READ,  ->Q3/ 

Q3 : RESTORE,  LEVEL,  ->Q1/.$ 


- 78  - 


The  last  example  shows  terminals  and  operations  with 
parameters.  The  concatenation  in  terminals  SUM  and  AND  en- 
sures that  the  results  are  at  least  16  bits  long,  even  for 
short  operands.  Note  that  the  actual  parameters  may  be  of 
varying  lengths,  and  the  formal  parameters  of  EXM  may  be 
used  as  the  actual  parameters  of  SUM  and  AND. 


Example  5 

MEMORY  RI1:16|. 

TERMINAL  S 1 1 1 : 2 ] « I NPUT (1 , S 1 ) , 

S 2 [ 1:2  1 = INPUT(  1 ,S2) , 

LI  M : 12]  = INPUT C 1 . L 1) , 

L 2 ( 1;  1 2 J = INPUT ( 1,L2), 

SUM  C A 1 , A 2 ) [ 1 : 16  1=(  16D0  CON  CAK  + 1A2))  TAIL  16, 
AND(A1,B2)(  1 : 16  ]=(  16D0  CON  ( A 1 * B2>)  TAIL  16. 
OPERATION  EXM ( X , Y ) a I 

R=SUM ( X , Y ) , OUTPUT( 1 , R) , 

R = AND ( X > Y ) , OUTPUT ( 1 , R ) J . 

CONTROL  Q.EXMCS1 ,S2) ,EXM(L1,L2) ,->Q/.$ 
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HOW  TO  RUN  DDL-P 

The  procedure  for  using  DDL-P  should  be  roughly  the 
same  on  any  TOPS-20  installation;  only  the  file  names  should 
diiier.  The  procedure  described  below  for  Stanford  LOTS  is 
typical . 


1.  Prepare  the  DDL-P  description.  The  file  contain- 
ing the  description  may  have  any  valid  file  name 
with  the  following  restrictions: 

i)  The  file  name  (excluding  extension)  must 
have  no  more  than  six  characters. 

ii)  The  extension  must  have  no  more  than  three 
characters . 

2.  Type  the  RUN  command  for  DDL-P.  At  Stanford  LOTS, 
the  command  is 

SKsources  . dd  l>dd  1 

3.  DDL-P  will  prompt  for  INPUT  and  OUTPUT  file  names. 
If  a directory  specification  is  to  be  supplied 
with  a file  name,  then  it  must  be  in  the  form  of  a 
PPN  in  brackets  following  the  file  name,  e.g.» 

DESC. DDL! 4, 524 ] 

The  INPUT  file  is  the  DDL-P  description.  A list- 
ing is  written  to  the  OUTPUT  file;  also,  any  simu- 
lation-time disk  output  goes  to  the  same  file. 

4.  DDL-P  will  now  ask  for  a third  file  name, 
"DDLINI  * ".  At  Stanford  LOTS,  respond  with  the 
file  name 

DDL. INI14, 1550 J 
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DDL-P 


5.  After  prompting  for  the  ebove  file  naaei, 
will  type 

TO  CONTINUE,  HIT  THE  RETURN  KEV  * 
end  wait  for  a line  of  input.  Just  press  <RETURN> 
to  get  sterted. 

6.  If  there  are  no  fatal  errors,  DDL-P  will  request 
the  radix  to  be  used  for  all  output.  Choose  base 
2,  4,  8,  10,  or  16. 

7.  The  H>M  prompt  will  be  printed  indicating  readi- 
ness to  accept  simulation  commands.  Use  of  the 
DDL-P  Simulator  is  described  in  DDL-P  Command  Lan- 
guage flag u at  (21. 


Chapter  1 1 

SAMPLE  COMPILER  OUTPUT 

The  listings  generated  by  the  DDL-P  compiler  for  tuo 
examples  from  Chapter  9 are  shown  on  the  next  two  pages. 
SIMADDR  is  an  internal  location  counter;  the  values  of  SI- 
MADDR  included  in  the  listing  are  useful  for  pinpointing  the 
places  where  simulation  errors  occur. 


SIMADDR 


0 

00100 

* 

B L A 

CKJACK  MACHI 

N E , " 

00200 

REGISTER  SCORE [ 5 ] , CARDBUF ( 5 ] , 

FF . * i 

00300 

TERMINAL  HIT,  BROKE,  STAND. 

00400 

VALUE  ( 1:51  « INPUT! 1 , VALUE ) , 

9 

00500 

YCRD 

« INPUT! 1 , YCRD) , 

18 

00600 

YL  1 7 

* SC0REC17,  YL 22  * SCORE<22, 

30 

00700 

NACE 

* CARDBUF# 1 . 

37 

00800 

OPERATION 

00900 

TPT 

* ( CARDBUF  <-  5D10  1, 

41 

01000 

TMT 

« ( CARDBUF  <-  5D22). 

45 

01100 

TVC 

* [CARDBUF  <-  VALUE  1 , 

50 

01200 

IHIT 

* lHIT=1B1  ), 

54 

01300 

I STD 

* [ STAND*  1 B 1 ] , IBRK  * [ BROKE*  1 B 1 ] , 

62 

01400 

CLS 

* l SCORE  <-  5D0 J , 

66 

0 1500 

ADD* 

[SCORE  <-!SCORE(+)CARDBUF)TAIL  5], 

76 

0 1600 

KFF 

= [FFC-1D01,  JFF  * IFF  <- 

1 D 1 ] 

84 

01700 

CONTROL 

86 

0 1800 

A: 

CLS,  KFF,  ->B/ 

96 

01900 

B: 

IHIT,  TVC, 

100 

02000 

IF  YCRD  THEN  ->C  ELSE  ->B 

ENDIF/ 

120 

02100 

C: 

IF  YCRD  THEN  ->C  ELSE  ->D 

ENDIF/ 

140 

02200 

D: 

ADD,  IF  NACE+FF  THEN  ->F 

• 

151 

02300 

ELSE  -> E 

ENDIF/ 

165 

02400 

E: 

JFF,  TPT,  ->D/ 

175 

02500 

Fs 

IF  YL 1 7 THEN  ->B  ELSE  ->G 

ENDIF/ 

195 

02600 

G: 

IF  YL22  THEN  ->K  ELSE  ->H 

ENDIF/ 

215 

02700 

H : 

KFF.  TMT, 

219 

02800 

IF  FF  THEN  ->D  ELSE  ->J  ENDIF/ 

239 

02900 

J : 

IBRK, 

241 

03000 

IF  YCRD  THEN  ->A  ELSE  ->J 

ENDIF/ 

261 

03100 

K: 

ISTD, 

263 

03200 

IF  YCRD  THEN  ->A  ELSE  ->K 

ENDIF/. $ 

END  OF 

TRANSLATION, 

0 FATAL  ERROR! S ) . 

MEMORY 

USE: 

ZSY  i 

31 

OUT 

OF 

1001  SYMBOL  TABLE  ENTRIES 

ZSTj 

26 

OUT 

OF 

5000  STRING  POINTERS 

ZI  i 

413  OUT 

OF 

22001  WORDS 

ZC: 

9 1 OUT 

OF 

4650  CHARACTERS 

ZB  : 

107  OUT 

OF 

71229  BITS 

SIMADDR 


0 

00100 

" EXAMPLE 

OF  INTERPRETIVELY  LINKED  MACHINE 

00200 

REGISTER 

A [ 16],  B [ 16),  ADDRt  8 ] . 

00300 

MEMORY 

MEM{ 0 : 255 , 16]. 

00400 

TERMINAL 

YCLR , YINC,  YADD,  YREAD , 

00500 

NDONE  = ADDR  t 255, 

6 

00600 

START  ■ INPUT  (1,  START). 

16 

00700 

OPERATION 

CLEAR  = [A  <-  1 6D0 , ADDR  <-  8D0], 

23 

00800 

INC  = [ADDR  <-  ADDR(+)8D1  TAIL  8 

32 

00900 

ADD  = [A  <-  A ( + ) B TAIL  16 ] , 

42 

0 1000 

READ  = [B  <-  MEMlADDR], 

48 

01100 

MEM[ ADDR ] = 16D0], 

54 

0 1200 

RESTORE  > [MEMlADDR]  ■ B]. 

61 

01300 

CONTROL 

63 

0 1400 

P 1 : 

IF 

START  THEN  YCLR  8,  YREAD  8,  ->P2 

75 

01500 

ELSE  ->P1  END I F/ 

89 

0 1600 

P2: 

YADD  8, 

92 

01700 

IF 

NDONE  THEN  YINC  8,  YREAD  8,  ->P2 

104 

01800 

ELSE  ->P1  ENDIF/ 

1 18 

01900 

CONTROL 

121 

02000 

Q1  : 

IF 

YINC  THEN  INC  ENDIF, 

132 

02100 

IF 

YCLR  THEN  CLEAR  ENDIF, 

143 

02200 

IF 

YADD  THEN  ADD  ENDIF, 

154 

02300 

IF 

YREAD  THEN  ->Q2 

160 

02400 

ELSE  — >Q 1 , LEVEL  ENDIF/ 

175 

02500 

02: 

READ,  ->03/ 

183 

02600 

Q3  : 

RESTORE,  LEVEL,  ->Ql/.$ 

END  OF 

TRANSLATION, 

0 

FATAL  ERROR! S ) . 

MEMORY 

USE: 

ZSY  s 

20 

OUT  OF 

1001  SYMBOL  TABLE  ENTRIES 

ZST  : 

277 

OUT  OF 

5000  STRING  POINTERS 

ZI  : 

322  OUT  OF 

22001  WORDS 

ZC« 

68  OUT  OF 

4650  CHARACTERS 

ZB: 

4238  OUT  OF 

71229  BITS 

Appendix  A 
ERROR  MESSAGES 

The  error  messages  issued  by  the  DDL-P  compiler  are 
listed  belou,  along  with  their  severity  codes.  Whc  ».  the 
compiler  detects  errors  in  the  DDL-P  description,  DDL-P 
lists  the  appropriate  error  message  both  at  the  teletype  and 
in  the  listing  file. 

DDL-P  will  halt  compilation  immediately  if  an  error  of 
severity  ABORT  appears.  Such  an  error  occurs  when  DDL-P 
runs  out  of  memory.  If  FATAL  errors  are  detected,  the  com- 
pilation will  proceed  to  completion,  but  simulation  uill  not 
be  alloued.  If  the  most  severe  errors  are  WARNINGS,  then 
simulation  uill  be  alloued. 

A brief  discussion  of  a feu  of  the  errors  follous  the 

list. 

fatal  Syntax  error 

uarning  Illegal  character 

uarning  Input  line  longer  than  132  characters 

fatal  Constant  too  large 

fatal  Illegal  number  length  spec,  (zero  or  >256) 

fatal  Decimal  number  may  not  be  1 ef t- jus t i f i ed 

fatal  Illegal  char,  or  digit  of  urong  radix  in  no. 

fatal  Digit  is  of  improper  radix 
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warning 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

warning 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

warning 

warning 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 


"END"  not  expected  here 

"THEM"  not  expected  here 

"ELSE"  not  expected  here 

"ENDIF"  not  expected  here 

"DO"  not  expected  here 

"ENDCASE"  not  expected  here 

";"  not  expected  here 

"."  not  expected  here 

Undeclared  identifier 

Multiply-defined  identifier 

Too  many  dimensions  (just  2 allowed) 

This  identifier  may  not  be  subscripted 
Two-dimensional  array  requires  subscript 
This  identifier  may  only  have  1 subscript 
Field  can't  be  used  to  denote  range  of  words 
Subscripting  nested  too  deeply  (>10  levels) 
Improper  field  or  access  to  non-existent  bits 
Too  many  dimensions  02)  or  invalid  field 
Formal  parameter  subscripted 
Predefined  terminal  subscripted 
More  than  63  arguments 
Missing  argument  list 
Wrong  number  of  arguments 
This  identifier  may  not  have  arguments 
This  identifier  not  allowed  in  expression 
Operation  identifier  not  allowed  in  expr. 
Output  operation  not  allowed  in  expression 
Need  >1  case  in  conditional  expression 
Constants  required  in  field  in  declaration 
State  sequencing  register  too  big 
State  sequencing  reg . can't  have  2 dimensions 
Predefined  terminal  may  not  have  2 dimensions 
Delayed  store  will  be  changed  to  immediate 
Immediate  store  will  be  changed  to  delayed 
More  than  two-part  concatenation 
Formal  parameter  may  not  appear  in  I/O  list 
Operation  identifier  not  allowed  in  I/O  list 
Predefined  terminal  not  allowed  in  input  list 
Improper  label  (wrong  type) 

Illegal  use  of  label  defined  in  other  section 
Undefined  state  label  referenced 
Undefined  statement  label  referenced 
Assignment  to  identifier  of  wrong  type 
Operand  must  be  terminal  (and  not  predefined) 
No  SSR  specified  for  this  I.L.M.  level 
Value  too  big  to  fit  into  SSR 
Same  SSR  value  assigned  to  different  states 
More  than  7 I.L.M.  levels  are  not  allowed 


warning 

fatal 

fatal 

fatal 

fatal 

fatal 

fatal 

abort 

abort 

abort 


"LEVEL"  in  top  level  I.L.M.  ignored 
Identifier  must  be  an  operation 
Identifier  must  be  a state 
Too  many  conditional  cases  (try  nesting) 
Conditionals  nested  too  deeply  (>10  levels) 
Unexpected  end  of  input 
Unexpected  end  of  file  or  program 
Internal  error:  parse  stack  overflow 
Internal  error:  symbol  table  overflow 
Internal  error:  memory  overflow 


The  term  "predefined  terminal"  refers  to  a terminal  for 
which  a function  was  specified  in  the  TERMINAL  declarations 
(Sections  6. 2-6. 3).  An  "argument"  is  the  same  as  an  "actual 
parameter . " 


The  abbreviation  "I.L.M."  stands  for  "interpretively 
linked  machine,"  Section  8.4,  while  "SSR"  stands  for  "state 
sequencing  register." 

The  message 

SYNTAX  ERROR 

flags  many  kinds  of  errors  in  DDL-P  descriptions.  In  case 
of  such  errors,  the  designer  should  refer  to  the  DDL-P  BNF 
to  determine  the  proper  syntax. 

DDL-P  allocates  table  space  of  2**n  words  for  a state 
sequencing  register  of  width  n bits.  The  message 
STATE  SEQUENCING  REGISTER  TOO  BIG 
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will  appear  only  if  the  register  is  wider  than  35  bits. 
However,  a MEMORY  OVERFLOW  problem  is  likely  for  state  se- 
quencing registers  wider  than,  say,  10  to  12  bits. 

The  error  message 

MORE  THAN  TWO-PART  CONCATENATION 
refers  only  to  concatenation  in  the  left  hand  side  of  an  im- 
mediate or  delayed  store  (•*  = •*  or  In  general,  an  ar- 

bitrary number  of  operands  may  be  concatenated  in  Boolean 
expressions.  (However,  the  width  of  the  result  must  not  ex- 
ceed 256  bits  . ) 

If  the  error 

TOO  MANY  CONDITIONAL  CASES  (TRY  NESTING) 
occurs  (it  won't  unless  the  number  of  conditional  cases  is 
well  into  the  hundreds),  then  it  may  be  corrected  by  nest- 
ing, as  illustrated  below.  The  two  examples  are  equivalent, 
but  the  one  on  the  right  uses  nesting. 


"NO  NESTING" 


"NESTING" 


CASE  C [ 1:4] 

DO  R(  1) 
DO  R(  2) 
DO  R C 3) 
DO  R C 4) 


DO  R C 5) 
DO  R ( 6) 
DO  R ( 7) 
DO  R ( 8) 


DO  R ( 9) 
DO  R(  10) 
DO  R( 11 ) 
DO  R(  1 2) 


DO  R( 13) 
DO  R( 14) 
DO  R ( 15) 
DO  R ( 0) 

ENDCASE 


CASE  Cl  1 : 2 } 

DO  CASE  C[ 3 : 4 ] 

DO  R ( 5) 
DO  R ( 6) 
DO  R ( 7) 
DO  R ( 4) 
ENDCASE 

DO  CASE  C[ 3 : 4 J 

DO  RC  9) 
DO  R ( 1 0 ) 
DO  R ( 1 1 ) 
DO  R ( 8) 
ENDCASE 

DO  CASE  C[3:4] 

DO  R(  13) 
DO  R(  14) 
DO  R( 1 5) 
DO  RC 1 2) 
ENDCASE 

DO  CASE  C[ 3 : 4 1 

DO  RC  1) 
DO  RC  2) 
DO  RC  3) 
DO  RC  0) 
ENDCASE 

ENDCASE 
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Appendix  B 
DDL-P  BHF 


! 


The  complete  Backus-Kaur  Form  for  DDL-P  is  listed  be- 
low. Non-terminals  are  written  in  lower-case  letters  and 
underscore;  "ddl_description"  is  a non-terminal*  e.g.  All 
other  symbols  are  terminals  except  for  the  following  special 
symbols  ("meta-symbols"): 

: : = REPLACEMENT  SYMBOL  - Left-hand  side  may  be 

replaced  by  right-hand  side. 

{ } OPTIONAL  STRING  SYMBOL  - String  of  symbols 

enclosed  in  braces  is  optional. 

{ }»**  REPETITION  SYMBOL  - String  of  symbols  enclosed 
may  appear  zero  or  more  times  in  succession. 

II  CONCATENATION  SYMBOL  - Symbol  on  left  must  be 

concatenated  with  symbol  on  right  (i.e.,  with  no 
intervening  blanks  or  end-of-1 ine) . 

I OR  SYMBOL  - This  separates  several  right-hand 

sides  of  productions. 
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In  • DDL  dasoription.  • conaint  is  any  string  oi  sym- 
bols sKospt  doubls-quots  (")  snolossd  in  doubls-quotss  and 
oontsinsd  on  ons  lino.  o.g..  "THIS  IS  A COMMENT" . A oommont 
may  appaar  anyuhara  a blank  is  parmittad. 


Tha  REGISTER.  MEMORY.  TERMINAL.  OPERATION.  and  CONTROL 


daolaration  sactions  may  ba  tarminatad  by  "END"  instaad  oi 
pariod  Tha  undorsoora  "_"  may  ba  uaod  as  tha  dalayad 
atora  action  in  placa  oi 


lattar  «»■  A I B 1C  I D I E I F lo I H 1 1 I J I K I L IM I 
NIOIPIQIRISITIUIVIUIXIYIZI 
alblcldlalilglhliljlklllml 
nlolplqlrlsltlulvlulxlylz 

digit  < >>  OM  1213141516171819 


hax_digi t 

» « ■ digit 

1 A 

1 B 1 C I D 1 

1 E i F 

octal_digit 

i i ■ 0 1 1 

1 2 

13  14  15 

16  17 

quartal_digit 

* * - 0 1 1 

1 2 

i 3 

bit  i i ■ 0 I 1 


dacimal_eonstant  ««■  digit  { 


digit  }»»• 


constant  ««■  dac ima l_cons tant 

I daeimal_constant  I I B { 


I dacimal.conatant 

{ 

I dacimal.constant 

{ 

I dac imal_conatant 
I dacimal_constant 


{ 


I .}  I I bit 

{ I I bit  )••* 
Q { I I . } 
quartal.digit 
q uar ta l_d ig i t )**» 
8(11.) 
octal_digi t 
octal_digi t } »•» 

D I I dacimal_constant 
H { I I . } 
hax_d ig i t 
hax_digi t 1««* 


letter_or_d ig i t ««»  letter  t digit 

identifier  t«»  letter  { II  lettar_or_digit  }**» 

field  t»»  booleen_exp  t boolean.exp 


I 


I 


j 


identi f ier_ref  ««*  identifier 


identifier 

identifier 

identifier 

identifier 

identifier 

identifier 

identifier 

identifier 

identifier 


I decimal_constant 
boolean_exp  ] 

I decimal_constant 

I boolean.exp 
boolean.exp  ) [ boolean_exp 
boolean_exp  , booleen_exp  ] 
field  ] 

I d ec ima l_c one t an t [ field  ] 
boolean.exp  ] ( field  ] 
boolean_exp  . field  ] 


terminal_ref  n*  identifier  ( boolean.exp 

{»  bool ean_exp} *»•  ) 

reference  «t«  identi f ier.ref  I terminal_ref 
boolean_exp  »«■  minterm  { ♦ minterm  }*«* 


minterm  ««■  product  { [ + 1 product  )*** 
product  it*  complement  { * complement  }**» 
complement  it*  {-}  reduction  { CON  reduction  }**• 


reduction  it*  adjustment 

I + RED  adjustment 
I * RED  adjustment 
I (+1  RED  adjustment 
I (+)  RED  adjustment 


adjustment  n*  relation 

I adjustment  EXT  ar i thmet ic_exp 
I adjustment  TAIL  ar i thmet i c_exp 
I adjustment  HEAD  arithmetic.exp 
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relation  ««■  ar i thmat lo_exp 

I ari thmat io_exp  <■) 
I ari thaat io_axp  • 

I ari thmat lc_axp  < 

I ari thmat io_exp  > 

I ar i t hmat i c_ax p >■ 
I ari thmat io_axp  <» 


ari thaat io_exp 
ari thmat io.exp 
a r i t hmat i o_axp 
ari thaatio.axp 
ari thmat io.exp 
ari thmat lo_exp 


ari thmat io_exp  it»  { (-)  } tara 

I ari thmat io_axp  (♦>  tarm 
I ari thmat ic_axp  (-)  tarm 


tara  i t ■ raiaranoa 

I INPUT(cona tant . i dent i i i ar_raf 

(.identiiier_rai)»»») 

I CASE  boolaan_axp  00  boolean_exp 

DO  boolean_exp 

( DO  boolean_exp  }*«•  ENDCASE 
I 4boolean_expt  boolaan_axp  » boolaan_axp 

{»  bool ean_axp) •••  . 

I IF  boolean_exp  THEN  boolean_exp 

ELSE  boolaan.exp  ENDIF 

I oonatant 
I ( boolaan_axp  ) 

ddl_dascription  »»■  daolaration  { oparat i on_dac 1 ) 

control_decl  (•) 

daolaration  <>■  rag i a t ar_dao 1 (mamor y_dec 1 ) 

{ tarminal_daol ) 

I memory_decl  { t armi  na  1 _d  ac  1 ) 

I t armi na l_dac 1 

ragiatar_daol  ««■  REGISTER  ragiatar.apea 

{ . rag iater.apeo  }•••  . 

regiater_spec  m (#}  idantiiiar 

{ t (oonatanti)  oonatant)  } 

I idantiiiar  ( {oonatanti}  conatant  , 
(oonatanti)  conatant  ) 

memory_deol  ii>  MEMORY  mamory.apac 

{ , memory_apeo  }•••  . 

mamory_apao  in  idantiiiar  U (oonatanti)  oonatant  )} 
I idantiiiar  ( (oonatanti)  oonatant  • 

(oonatanti)  oonatant  ) 


* 
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t erainal_dec 1 «t»  TERMINAL  terminal_epec 

{ » terminal_spec  }»** 


tarainal_spac  n»  identifier 

( I {constant)}  constant  ] } 

I idantifiar  [ (constant))  constant  , 
(constant)}  constant  I 

I idantifiar 

{ (idantifiar  (,  idantifiar} ***  ) } 
( [(constant)}  constant]  } 

* boolean_exp 


opsrat ion_dac 1 »>■  OPERATION  oparation_daf 

(*  opsrat i on_daf }*** 


operat ion_daf  >>•  idantifiar 

{ (idantifiar  {.idantifiar}***  ) } 
■ ( action  {»  action}***  I 


action  n»  idantif iar_raf  (CON  idanti f i ar.raf } 

<-  boolean_axp 

I idantif iar.raf  (CON  idant i f i ar.raf ) 

■ boolean_axp 

I idantif iar_raf  a 

I INPUT  ( constant  , idant i f i er_ref 

( » idantif ier_ref  }***  ) 

I OUTPUT  ( constant  . rafaranca 

{ . rafaranca  }***  ) 

I idantifiar  { ( boolaan_exp 

( » boolean_exp  }***  ) } 

I CASE  boolaan^axp 

DO  action  { • action  }*** 

( DO  action  { , action  }***  }***  ENDCASE 
I tbool ean.expt 

action  { • action  }*** 

{ j action  { , action  }«**  }**«  . 
t IF  boolaan.axp 

THEN  action  { » action  }•»* 

( ELSE  action  { > action  }•**  } ENDIF 
I TIME  boolaan_axp 
I ->  idantifiar 
I idantifiar  > action 


oontrol_dael  ))■  laval_dacl  { level_decl  )»** 


leval_dacl  >>■  CONTROL  atata_daf  ( stata_daf  }*** 


»»■  (idantiiiar  { (constant)  } t) 

( *tata_aation  {,  s tita_act ion) ) / 


• tat •..act ion  < i ■ 

idantiiiar  { (boolaan.axp  { , boolaan.axp) •*•)  } 

I idanti i iar.rai  S 
I ->  idantiiiar 
I ■>  idantiiiar 
I RETURN 

I CASE  boolaan.axp 

DO  atata.action  {,  • ta ta__acti on) 

C DO  atata.action  {,  a tata.act ion) **•  }••» 
ENDCASE 

I ♦boolaan.axp*  atata.action  { ,atata.aotion)«*« 

{>  atata.action 

(»  s tata_act ion) •••  )••*  . 

I IF  boolaan.axp 

THEN  atata.action  {,  s tata_ac t i on) ••• 

{ ELSE  atata.action  {,  a tat a.ac t i on) •••  ) 
ENDXF 
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